854139 - crash in nsJSIID::HasInstance

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Scoobidiver (away)]

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

Comment 1

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Sounds an awful lot like Bobby.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Bobby Holley (:bholley)]

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

Comment 4

[Attila Soki]

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

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

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

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(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

Comment 7

[Bobby Holley (:bholley)]

Attachment: Handle all DOM objects, not just ones that unwrap to nsISupports. v1

Excellent - thanks for the STR Honza.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

r=me

Comment 9

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6422928d26e4

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? 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

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6422928d26e4

Comment 14

[Jan Honza Odvarko [:Honza] (always need-info? me)]

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

Comment 15

[Scoobidiver (away)]

There have been no crashes since 22.0a1/20130329.