4 ms·

As long as Apple's allocator continues to zero freed memory, programs accidentally depending on that behavior will only be a problem for other operating systems

As long as Apple's allocator continues to zero freed memory, programs accidentally depending on that behavior will only be a problem for other operating systems.

cesarb 4y ago
> As long as Apple's allocator continues to zero freed memory, programs accidentally depending on that behavior will only be a problem for other operating systems. As I mentioned, only until that freed block is reused for a new allocation, which means it will no longer be all-zeros; or until the memory allocator decides it's time to unmap that region, which means it will trap (SIGSEGV or similar).
- kergonath 4y ago
  > which means it will trap Is it really a problem? Failing harder and earlier is a good thing if it means the bug has more chances of being detected and fixed.
- ncmncm 4y ago
  Memory allocators generally don't unmap anything, because the performance hit on any other threads running is severe. When memory is unmapped, caches of memory mappings of other threads are discarded, via inter-core interrupts. Then they get misses until their cache is restored. In what might be a multi-thread program, you don't fool with the memory map without very good reasons. Mapping new pages, or marking a page r/o or r/w is OK; anything else, probably not.
  - zerohp 4y ago
    > When memory is unmapped, caches of memory mappings of other threads are discarded, via inter-core interrupts. ARM architecture does not need to interrupt for TLB shootdown.
Taniwha 4y ago
Possibly but there's the potential reverse problems where Apple programs start depending on newly allocated memory being zero .... and those programs start failing elsewhere ...
- ncmncm 4y ago
  Might fail there, too, but only sometimes, if the memory gets allocated again.
- thewebcount 4y ago
  Well the change is to zero out memory on deallocation. So on allocation it may or may not be zero depending on whether it was previously freed, right?
  - Taniwha 4y ago
    not necessarily, even if was freed there might be defragged free blocks that still contain heap metadata by the time it gets reallocated
ajross 4y ago
Or until the particular allocation moves to a custom/separate heap or other non-system-malloc allocator. That sort of tuning is very common in big apps.

As long as Apple's allocator continues to zero freed memory, programs accidentally depending on that behavior will only be a problem for other operating systems.

cesarb 4y ago

> As long as Apple's allocator continues to zero freed memory, programs accidentally depending on that behavior will only be a problem for other operating systems. As I mentioned, only until that freed block is reused for a new allocation, which means it will no longer be all-zeros; or until the memory allocator decides it's time to unmap that region, which means it will trap (SIGSEGV or similar).

kergonath 4y ago
> which means it will trap Is it really a problem? Failing harder and earlier is a good thing if it means the bug has more chances of being detected and fixed.
ncmncm 4y ago
Memory allocators generally don't unmap anything, because the performance hit on any other threads running is severe. When memory is unmapped, caches of memory mappings of other threads are discarded, via inter-core interrupts. Then they get misses until their cache is restored. In what might be a multi-thread program, you don't fool with the memory map without very good reasons. Mapping new pages, or marking a page r/o or r/w is OK; anything else, probably not.
- zerohp 4y ago
  > When memory is unmapped, caches of memory mappings of other threads are discarded, via inter-core interrupts. ARM architecture does not need to interrupt for TLB shootdown.

Taniwha 4y ago

Possibly but there's the potential reverse problems where Apple programs start depending on newly allocated memory being zero .... and those programs start failing elsewhere ...

ncmncm 4y ago
Might fail there, too, but only sometimes, if the memory gets allocated again.
thewebcount 4y ago
Well the change is to zero out memory on deallocation. So on allocation it may or may not be zero depending on whether it was previously freed, right?
- Taniwha 4y ago
  not necessarily, even if was freed there might be defragged free blocks that still contain heap metadata by the time it gets reallocated

ajross 4y ago

Or until the particular allocation moves to a custom/separate heap or other non-system-malloc allocator. That sort of tuning is very common in big apps.