1790952 - Mac instrumented build crash with EXC_BAD_INSTRUCTION @_os_unfair_lock_recursive_abort

Status: NEW

(Firefox Build System :: General, defect, P3)

Description

[Mike Hommey [:glandium]]

Filing for the record because it doesn't affect us directly, but when LLVM_PROFILE_FILE is not set, instrumented builds (builds with --enable-profile-generate) crash with the following backtrace:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x00007fff2036e517 libsystem_platform.dylib`_os_unfair_lock_recursive_abort + 23
    frame #1: 0x00007fff203691a5 libsystem_platform.dylib`_os_unfair_lock_lock_slow + 258
    frame #2: 0x00007fff202540e2 libsystem_c.dylib`getenv + 34
    frame #3: 0x0000000100146c49 libmozglue.dylib`logalloc_init + 25
    frame #4: 0x00000001001374dd libmozglue.dylib`init() + 157
    frame #5: 0x0000000100137790 libmozglue.dylib`malloc + 80
    frame #6: 0x00007fff20166dfe libsystem_malloc.dylib`_malloc_zone_malloc + 118
    frame #7: 0x00007fff20258d9f libsystem_c.dylib`__setenv_locked + 369
    frame #8: 0x00007fff2025928a libsystem_c.dylib`setenv + 140
    frame #9: 0x00000001001ffb10 libmozglue.dylib`truncateCurrentFile + 96
    frame #10: 0x00000001001ff08e libmozglue.dylib`parseAndSetFilename + 958
    frame #11: 0x00000001001ff233 libmozglue.dylib`__llvm_profile_initialize + 99
    frame #12: 0x0000000100034079 dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 559
    frame #13: 0x0000000100034478 dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
    frame #14: 0x000000010002ed1a dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 492
    frame #15: 0x000000010002ec85 dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 343
    frame #16: 0x000000010002cb82 dyld`ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 188
    frame #17: 0x000000010002cc22 dyld`ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 82
    frame #18: 0x000000010001962f dyld`dyld::initializeMainExecutable() + 199
    frame #19: 0x000000010001f9a4 dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 8288
    frame #20: 0x000000010001822b dyld`dyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) + 457
    frame #21: 0x0000000100018025 dyld`_dyld_start + 37

The problem is the instrumentation initialization calls setenv, which gets the environment lock, and then allocates memory, but it's the first time the allocator is called, so the allocator initializes itself, and calls getenv, ... which tries to get the environment lock and crashes because it's already locked on the same thread.

The more interesting part here is that this wouldn't happen if our allocator wasn't registered to the system zone allocator, which reveals that the allocator initialization code is actually running before the instrumentation initialization code...