mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-24 05:11:16 +00:00
352bb98f8e
The global allocator we define for Rust code directs all Rust allocations to the malloc family of functions. Practically speaking, it's a no-op on Unix systems (the default global allocator would do the same thing except for tiny details about alignment on some platforms), but it makes a big difference on Windows, where the Rust default global allocator uses the HeapAlloc family of functions. Well, in practice, it doesn't make a huge difference, because we wrap those functions to fall back to the malloc family of functions. But it does make a difference in how allocations with large alignment are handled (because it does its own alignment on top of HeapAlloc). We're about to stop wrapping the HeapAlloc family of functions, because it's causing other problems with memory that might have been HeapAlloc'ated from system libraries, which a wrapped HeapFree can't handle without overhead. But, we're only currently defining the Rust global allocator when mozjemalloc is enabled, meaning removing the wrapping gets us back to Rust using HeapAlloc/HeapFree on those builds. Unfortunately, that exchanges of ownership between C/C++ and Rust can lead to allocator mismatch (and subsequent heap corruption). One specific case where this causes problems is ASan builds, which disable mozjemalloc specifically to enable the ASan allocator. So we need to always define a Rust global allocator that uses the malloc family of functions, whether or not mozjemalloc is enabled. Unfortunately, the current code also relies on _aligned_malloc being redirected to mozjemalloc, so we also need to adjust it to call _aligned_free to free the corresponding memory on builds where mozjemalloc is not enabled. Differential Revision: https://phabricator.services.mozilla.com/D205787 |
||
|---|---|---|
| .. | ||
| android | ||
| baseprofiler | ||
| build | ||
| interposers | ||
| linker | ||
| misc | ||
| static | ||
| tests | ||
| moz.build | ||