This isn't fixed. I used a HookCase (https://github.com/steven-michaud/HookCase) hook library to trigger a crash in __CFRunLoopDoSource0() on a MacBook Pro (Retina, 15-inch, Mid 2015) with a Haswell+ CPU, running macOS 10.15.1 (the current Catalina release). The CoreFoundation framework has both x86_64 and x86_64h architectures, as shown by the output of `dump_syms -i -a [arch]` on my machine's copy of it: MODULE mac x86_64 09EB9DD025BC37309716FE231CAF2C700 CoreFoundation MODULE mac x86_64h 15D61616B29B3BDB86244B84A49564850 CoreFoundation But the stack trace for the crash (bp-dbaba15a-fbbb-48ff-b117-d324e0191103) has incorrect symbols for the CoreFoundation elements of the stack trace: 1 CoreFoundation __CFRunLoopServiceMachPort 2 CoreFoundation __CFRunLoopRun 3 CoreFoundation __CFRunLoopModeIsEmpty These should be: 1 CoreFoundation __CFRunLoopDoSources0 2 CoreFoundation __CFRunLoopRun 3 CoreFoundation __CFRunLoopRunSpecific In the raw dump (https://crash-stats.mozilla.org/report/index/dbaba15a-fbbb-48ff-b117-d324e0191103#tab-rawdump) I notice that the CoreFoundation module's "debug_id" is 09EB9DD025BC37309716FE231CAF2C700 -- which corresponds to the incorrect architecture. And in the result of `minidump_stackwalk -m` on the crash minidump, the following shows up in the results: Module|CoreFoundation||CoreFoundation|09EB9DD025BC37309716FE231CAF2C700|0x7fff2bd1b000|0x7fff2c19afff|0 So Mozilla's breakpad client has already picked the wrong architecture before the crash minidump gets uploaded to Socorro, and processed there. The symbol server now has symbols for both architectures (x86_64 and x86_64h) of CoreFoundation. The symbols I scraped at bug 1588843 comment 63 are on the symbol server (I just checked by running gathersymbols.py again). So that can't be the cause of this problem. I'll look for the current version of the code that Ted mentioned in comment 1, and see what possible errors I can find there.
Bug 1371390 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This isn't fixed. I used a HookCase (https://github.com/steven-michaud/HookCase) hook library to trigger a crash in __CFRunLoopDoSource0() on a MacBook Pro (Retina, 15-inch, Mid 2015) with a Haswell+ CPU, running macOS 10.15.1 (the current Catalina release). The CoreFoundation framework has both x86_64 and x86_64h architectures, as shown by the output of `dump_syms -i -a [arch]` on my machine's copy of it: MODULE mac x86_64 09EB9DD025BC37309716FE231CAF2C700 CoreFoundation MODULE mac x86_64h 15D61616B29B3BDB86244B84A49564850 CoreFoundation But the stack trace for the crash (bp-dbaba15a-fbbb-48ff-b117-d324e0191103) has incorrect symbols for the CoreFoundation elements of the stack trace: 1 CoreFoundation __CFRunLoopServiceMachPort 2 CoreFoundation __CFRunLoopRun 3 CoreFoundation __CFRunLoopModeIsEmpty These should be: 1 CoreFoundation __CFRunLoopDoSources0 2 CoreFoundation __CFRunLoopRun 3 CoreFoundation __CFRunLoopRunSpecific In the raw dump (https://crash-stats.mozilla.org/report/index/dbaba15a-fbbb-48ff-b117-d324e0191103#tab-rawdump) I notice that the CoreFoundation module's "debug_id" is 09EB9DD025BC37309716FE231CAF2C700 -- which corresponds to the incorrect architecture. And in the result of `minidump_stackwalk -m` on the crash minidump, the following shows up: Module|CoreFoundation||CoreFoundation|09EB9DD025BC37309716FE231CAF2C700|0x7fff2bd1b000|0x7fff2c19afff|0 So Mozilla's breakpad client has already picked the wrong architecture before the crash minidump gets uploaded to Socorro, and processed there. The symbol server now has symbols for both architectures (x86_64 and x86_64h) of CoreFoundation. The symbols I scraped at bug 1588843 comment 63 are on the symbol server (I just checked by running gathersymbols.py again). So that can't be the cause of this problem. I'll look for the current version of the code that Ted mentioned in comment 1, and see what possible errors I can find there.