With the below stack trace, it first showed up in 22.0a1/20130323. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e9badd3cf39&tochange=3825fdbcec62 Signature XPCWrappedNative::HasInterfaceNoQI(nsID const&) More Reports Search UUID 5d1baa42-a6a4-41a0-b0bf-224dc2130323 Date Processed 2013-03-23 15:51:49 Uptime 29 Install Age 29 seconds since version was first installed. Install Time 2013-03-23 15:37:05 Product Firefox Version 22.0a1 Build ID 20130323031040 Release Channel nightly OS Mac OS X OS Version 10.7.5 11G63 Build Architecture amd64 Build Architecture Info family 6 model 37 stepping 2 Crash Reason EXC_BAD_ACCESS / 0x0000000d Crash Address 0x0 User Comments tried to open dev tools - sigh App Notes AdapterVendorID: 0x8086, AdapterDeviceID: 0x 46GL Context? GL Context+ GL Layers? GL Layers+ Processor Notes sp-processor05.phx1.mozilla.com_7968:2008; exploitablity tool: ERROR: unable to analyze dump EMCheckCompatibility True Adapter Vendor ID 0x8086 Adapter Device ID 0x 46 Frame Module Signature Source 0 XUL XPCWrappedNative::HasInterfaceNoQI js/xpconnect/src/xpcprivate.h:2410 1 XUL nsJSIID::HasInstance js/xpconnect/src/XPCJSID.cpp:538 2 XUL js::Shape::search js/src/vm/Shape.h:1060 3 XUL js::ObjectImpl::nativeLookup js/src/vm/ObjectImpl.cpp:303 4 XUL int js::baseops::LookupProperty< js/src/jsobj.cpp:3461 5 XUL _ZThn8_N7nsJSIID11HasInstanceEP25nsIXPConnectWrappedNativeP9JSContextP8JSObjectR js/xpconnect/src/XPCJSID.cpp:556 6 XUL XPC_WN_Helper_HasInstance js/xpconnect/src/XPCWrappedNativeJSOps.cpp:976 7 XUL js::HasInstance js/src/jsinterp.cpp:580 8 XUL js::mjit::stubs::InstanceOf js/src/methodjit/StubCalls.cpp:1208 9 XUL js::mjit::EnterMethodJIT js/src/methodjit/MethodJIT.cpp:1042 10 XUL js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:1100 11 XUL js::Interpret js/src/jsinterp.cpp:2453 12 XUL nsFont::~nsFont nsTSubstring.h:85 13 XUL nsLineLayout::PlaceTopBottomFrames layout/generic/nsLineLayout.cpp:1529 14 XUL nsOverflowAreas::UnionWith nsHTMLReflowMetrics.cpp:16 15 XUL nsInlineFrame::IsSelfEmpty layout/style/nsStyleStructList.h:108 16 XUL nsBlockFrame::PlaceLine layout/generic/nsBlockFrame.cpp:4237 17 libsystem_c.dylib libsystem_c.dylib@0xa11a4 18 XUL nsBlockFrame::ReflowInlineFrame layout/generic/nsBlockFrame.cpp:3735 19 libmozglue.dylib arena_dalloc jemalloc.c:1699 20 libsystem_c.dylib libsystem_c.dylib@0xa0789 21 XUL nsBlockFrame::ReflowInlineFrames layout/generic/nsBlockFrame.cpp:3417 ... More reports at: https://crash-stats.mozilla.com/report/list?signature=XPCWrappedNative%3A%3AHasInterfaceNoQI%28nsID+const%26%29 https://crash-stats.mozilla.com/report/list?signature=XPCWrappedNative%3A%3AGetSet%28%29+const https://crash-stats.mozilla.com/report/list?signature=nsJSIID%3A%3AHasInstance%28nsIXPConnectWrappedNative*%2C+JSContext*%2C+JSObject*%2C+JS%3A%3AValue+const%26%2C+bool*%2C+bool*%29

Sounds an awful lot like Bobby.

The part of the stack up to about frame 6 makes sense. The part after that.... I'm not sure. Landing at the line in frame 1 is reasonable, but the JS stuff in between is daft. In any case, is it possible that mInfo->GetIIDShared() is returning a null id here somehow? Seems dubious.

This crash is almost certainly the result of this patch: http://hg.mozilla.org/mozilla-central/rev/ddd198e0e288 However, I'm still stumped. If we get past the call to FindObjectForHasInstance with a non-null |obj|, then either it should pass the IS_WRAPPER_CLASS check or the IsDOMObject check. So it should be a reflector. If it's a slim wrapper, we should morph it, and bail if that fails. If it's a DOM object, we unconditionally return. So we should be ending up with a WN by the time we call XPCWrappedNative::Get, and we even null check the value we pull out of the private. At the crash site, it would seem like either the XPCWN* or the iid is null. But it's not clear why. If we care enough to spend resources here, the next steps would be one of: * getting repro steps * getting me a minidump I can look at * landing a diagnostic patch

playing around with firebug 1.12.0a3 and the 'Empty Cache Button 2.1' addon. 1. install firebug 1.12.0a3 and 'Empty Cache Button 2.1' 2. restart Firefox 3. open www.mozilla.org 4. press the empty cache button 5. open firebug 6. reload with cmd+r 7. press empty cache button 8. close firebug with the (x) on the right top corner 9. goto 4 or 6 or 7. and somewhere between after a button press you will get a crash. bp-86494791-560f-4790-a16b-53e1c2130326 bp-84611564-c934-4635-ac69-1d4a62130325 bp-d75dd00a-97f8-411d-ae68-757f62130326

It happens since changeset 3825fdbcec62 for Firebug (as Boris also mentioned). Another STR: 1. Install Firebug 1.12.0a3 https://getfirebug.com/releases/firebug/1.12/firebug-1.12.0a3.xpi 2. Install also FBTest (Firebug automated test harness) https://getfirebug.com/releases/fbtest/1.12/fbTest-1.12b2.xpi 3. Open the Test Console, Firebug (icon) menu -> Open Test Console 4. Load test list: https://getfirebug.com/tests/head/firebug.html (should be done automatically) 5. Run Test: firebug/2613 (or press 'Run All' and wait, it's the 20th test, which causes the crash). Honza

(In reply to Jan Honza Odvarko from comment #5) > It happens since changeset 3825fdbcec62 for Firebug (as Boris also > mentioned). > > Another STR: > 1. Install Firebug 1.12.0a3 > https://getfirebug.com/releases/firebug/1.12/firebug-1.12.0a3.xpi > > 2. Install also FBTest (Firebug automated test harness) > https://getfirebug.com/releases/fbtest/1.12/fbTest-1.12b2.xpi > > 3. Open the Test Console, Firebug (icon) menu -> Open Test Console > 4. Load test list: https://getfirebug.com/tests/head/firebug.html > (should be done automatically) Update: you need to use this test list: https://getfirebug.com/tests/head/known-failures.html I have removed the test that causes the crash from the main list (to see results from other tests). Honza

Excellent - thanks for the STR Honza.

Comment on attachment 730442 [details] [diff] [review] Handle all DOM objects, not just ones that unwrap to nsISupports. v1 r=me

I updated the known-failures test list: https://getfirebug.com/tests/head/known-failures.html It now contains 18 tests that cause Firefox to crash. As soon as you have the patch finished, you can try to run them all. Honza

I can confirm that Firefox doesn't crash with Firebug anymore. Thanks! Honza

There have been no crashes since 22.0a1/20130329.