1376567 - Calling fork() during shutdown on Mac leads to a crash due to memory allocations

Status: RESOLVED WORKSFORME

(Core :: Memory Allocator, defect, P3)

Description

[Gabriele Svelto [:gsvelto]]

This is something we've experienced dealing with the crashreporter client as well as the pingsender. Apparently fork() on Mac is doing some memory allocations (possibly related to locking) so if it gets called late enough during shutdown it crashes the parent process.

Comment 1

[Gabriele Svelto [:gsvelto]]

Ted, I can't find the bug where we hit this. Do you remember which one it was? It would be great to have that stack trace showing the problem in action.

Comment 2

[(not currently active) Ted Mielczarek]

That was bug 1356673.

Comment 3

[(not currently active) Ted Mielczarek]

From my reading of the crash stacks from that bug, it looked like something was going wrong with the way jemalloc hooked into the system heap. attachment 8858399 [details] shows the forked process was crashing in libsystem_malloc in nano_reinit_lock by way of libSystem_atfork_child. I don't really know enough about our jemalloc implementation or OS X's system malloc to say anything more useful here, but I'd guess that something jemalloc is doing is not fork-safe.

Comment 4

[Gabriele Svelto [:gsvelto]]

Mike, we spoke about this during the all-hands closing party, in case you want to have a look :)

Comment 5

[Gabriele Svelto [:gsvelto]]

Clearing the needinfo since we've moved the affected code to use posix_spawnp(). Since fork() has other issues on Mac this is probably not worth investigating.

Comment 6

[Pablo]

Hi gabriele, we are checking on really old bugs trying to find what can be closed either because of old functionality or something that has been fixed already on latest versions. I would like to know if this bug is still happening or is there any newer crash report link?
should we keep it open?

thanks

Comment 7

[Gabriele Svelto [:gsvelto]]

The bug is still valid, we just avoid using fork() on macOS. Feel free to close this given we simply try to avoid triggering this bug in new code.

Comment 8

[Pablo]

per last comment, changing bug to resolved WFM