plugin-container crashes, where is XUL DWARF .dSYM?

Benjamin Smedberg

2014-02-12 17:05:35 UTC

Post by H
My plugin seems to be crashing and I don't find any trace in my code trace. The following seems to be the stack trace generated on Mac OS X. This happens in a random fashion, I can't get the exact scenario. Where do I find the DWARF .dSYM files for the XUL library?

We don't publish these for mac. We do have breakpad .sym files which can
be used with other breakpad tools like minidump-stackwalk to produce a
stacktrace from a crash minidump, but that doesn't sound like it will
precisely solve the problem you have here.

The best thing to do here if you want to get good symbols from XUL is
just build Firefox yourself. It's not super hard.

Post by H
Or can somebody comment on why this has caused the crash?
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x00007fff88418647 CFRelease + 39
1 com.apple.CoreFoundation 0x00007fff884278c8 __CFBasicHashDrain + 408
2 com.apple.CoreFoundation 0x00007fff884187c8 CFRelease + 424
3 com.apple.CoreFoundation 0x00007fff88470720 CFRunLoopSourceInvalidate + 160
4 com.apple.CFNetwork 0x00007fff92589ad4 MultiplexerSource::unschedule(CoreSchedulingSet const*, MultiplexerClient*) + 152
5 com.apple.CFNetwork 0x00007fff925899ee RunLoopMultiplexer::unschedule(CoreSchedulingSet const*, MultiplexerClient*) + 68
6 com.apple.CFNetwork 0x00007fff9258993d RunloopBlockContext::~RunloopBlockContext() + 69
7 com.apple.CFNetwork 0x00007fff925898cf RunloopBlockContext::~RunloopBlockContext() + 15
8 com.apple.CFNetwork 0x00007fff9256f3a7 RunloopBlockContext::perform() + 319
9 com.apple.CFNetwork 0x00007fff9256f183 MultiplexerSource::perform() + 269
10 com.apple.CFNetwork 0x00007fff9256efb2 MultiplexerSource::_perform(void*) + 72
11 com.apple.CoreFoundation 0x00007fff8847e8f1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
12 com.apple.CoreFoundation 0x00007fff88470062 __CFRunLoopDoSources0 + 242
13 com.apple.CoreFoundation 0x00007fff8846f7ef __CFRunLoopRun + 831
14 com.apple.CoreFoundation 0x00007fff8846f275 CFRunLoopRunSpecific + 309
15 com.apple.HIToolbox 0x00007fff8aa60f0d RunCurrentEventLoopInMode + 226
16 com.apple.HIToolbox 0x00007fff8aa60cb7 ReceiveNextEventCommon + 479
17 com.apple.HIToolbox 0x00007fff8aa60abc _BlockUntilNextEventMatchingListInModeWithFilter + 65
18 com.apple.AppKit 0x00007fff90b5d28e _DPSNextEvent + 1434
19 com.apple.AppKit 0x00007fff90b5c8db -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
20 com.apple.AppKit 0x00007fff90b509cc -[NSApplication run] + 553
21 XUL 0x000000010145d03f 0x100007000 + 21323839
22 XUL 0x000000010145cb26 0x100007000 + 21322534
23 XUL 0x000000010144f52d 0x100007000 + 21267757
24 XUL 0x0000000100015dad XRE_InitChildProcess + 1357
25 org.mozilla.plugincontainer 0x0000000100000f1a 0x100000000 + 3866
26 org.mozilla.plugincontainer 0x0000000100000ee4 start + 52

The stack here actually looks pretty accurate. The apple networking
stack is calling into CoreFoundation which is crashing. The
plugin-container code is just spinning a normal event loop and probably
isn't involved in the crash at all. I do have a couple notes:

* In general plugins should avoid doing their own networking. It is much
better to use the NPAPI geturl functions to do your networking because
they honor the user proxy settings, cookies, etc.

* CFRelease crashes are probably just an extra release on the object. I
don't know exactly what kind of object it is, but you should audit your
code for mismatched calls to CFRelease/CFRetain in case you have an
extra release.

--BDS