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

On 2/12/2014 7:18 AM, H wrote:
> 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.

>
> 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