Closed Bug 854139 Opened 11 years ago Closed 11 years ago

crash in nsJSIID::HasInstance


(Core :: XPConnect, defect)

22 Branch
Not set



Tracking Status
firefox21 --- unaffected
firefox22 + verified


(Reporter: scoobidiver, Assigned: bholley)



(4 keywords)

Crash Data


(1 file)

With the below stack trace, it first showed up in 22.0a1/20130323. The regression range is:

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 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:*%2C+JSContext*%2C+JSObject*%2C+JS%3A%3AValue+const%26%2C+bool*%2C+bool*%29
Sounds an awful lot like Bobby.
Assignee: nobody → bobbyholley+bmo
Blocks: 658909
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:

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

Keywords: reproducible
It happens since changeset 3825fdbcec62 for Firebug (as Boris also mentioned).

Another STR:
1. Install Firebug 1.12.0a3

2. Install also FBTest (Firebug automated test harness)

3. Open the Test Console, Firebug (icon) menu -> Open Test Console
4. Load test list:
(should be done automatically)

5. Run Test: firebug/2613 (or press 'Run All' and wait, it's the 20th test, which causes the crash).

Keywords: topcrash
(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
> 2. Install also FBTest (Firebug automated test harness)
> 3. Open the Test Console, Firebug (icon) menu -> Open Test Console
> 4. Load test list:
> (should be done automatically)

Update: you need to use this test list:

I have removed the test that causes the crash from the main list
(to see results from other tests).

Excellent - thanks for the STR Honza.
Attachment #730442 - Flags: review?(bzbarsky)
Comment on attachment 730442 [details] [diff] [review]
Handle all DOM objects, not just ones that unwrap to nsISupports. v1

Attachment #730442 - Flags: review?(bzbarsky) → review+
I updated the known-failures test list:

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.

Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
I can confirm that Firefox doesn't crash with Firebug anymore.
There have been no crashes since 22.0a1/20130329.
You need to log in before you can comment on or make changes to this bug.