630877 - Crash [@ nsGenericElement::GetPrimaryFrame(mozFlushType) ]

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Scoobidiver (away)]

It is a residual crash signature that exists in 3.6 and the trunk. There is a
spike in crashes from 4.0b11pre/20110130.
It is #67 top crasher in 4.0b11pre over the last 3 days.

Signature	nsGenericElement::GetPrimaryFrame(mozFlushType)
UUID	a0c9b991-56ef-4f74-b651-e33fb2110202
Time 	2011-02-02 05:41:19.244137
Uptime	14144
Last Crash	14160 seconds (3.9 hours) before submission
Install Age	85415 seconds (23.7 hours) since version was first installed.
Product	Firefox
Version	4.0b11pre
Build ID	20110201030339
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 10
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0xc
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0640, AdapterDriverVersion: 8.17.11.9621

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsGenericElement::GetPrimaryFrame 	content/base/src/nsGenericElement.cpp:3754
1 	xul.dll 	nsGenericElement::GetBoundingClientRect 	content/base/src/nsGenericElement.cpp:1737
2 	xul.dll 	nsNSElementTearoff::GetBoundingClientRect 	content/base/src/nsGenericElement.cpp:1752
3 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
4 	xul.dll 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1593
5 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4780
6 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:657
7 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:737
8 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
9 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:5075
10 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1701
11 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
12 	xul.dll 	SelectorMatches 	layout/style/nsCSSRuleProcessor.cpp:1730
13 	kernel32.dll 	InterlockedExchangeAdd 	

The regression range for the spike is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=94a51a3b64d4&tochange=336d5906cb0f

More reports at:
https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0b11pre&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsGenericElement%3A%3AGetPrimaryFrame%28mozFlushType%29

Comment 1

[Boris Zbarsky [:bzbarsky]]

The crashes are at 0xc == 12 on 32-bit and 0x18 == 24 on 64-bit, so three words into the object.  The code line where we crash is:

  nsIDocument* doc = GetCurrentDoc();

The first 4 words of an nsINode are the vtable pointer, mWrapperPtrBits, mNodeInfo, and mParentPtrBits.

GetCurrentDoc() has to access mParentPtrBits.  Which means that |this| is null in that GetPrimaryFrame call.

Peter, is it possible that nsNSElementTearoff::GetBoundingClientRect is called when mContent is null?  Doesn't seem like that should happen, unless it's been unlinked....

Comment 2

[Boris Zbarsky [:bzbarsky]]

Even ccing Peter.

Comment 3

[Boris Zbarsky [:bzbarsky]]

And how are we landing in nsNSElementTearoff::GetBoundingClientRect anyway?  This should be quickstubbed, no?  That worries me....

Comment 4

[Peter Van der Beken [:peterv]]

We should, but could be that the quickstub was removed from the prototype?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm.  Possible, I suppose.

But I still don't see how mContent could be null there.

Comment 6

[Peter Van der Beken [:peterv]]

If it's been unlinked, that would mean we've somehow managed to return a wrapper to JS for a node that has already been unlinked.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Or that we unlinked but then didn't GC and the JS reflection is still around?  Bug 624549 is in the regression range...

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

This looks like the other bugs I'm hoping bug 614347 will fix.

Comment 10

[Damon Sicore (:damons)]

Need an owner here immediately.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

This depends on bug 614347. That should fix the problem with tearoff objects and
unlinking.

Comment 12

[Mike Shaver (:shaver emeritus)]

Bug 614347 landed tonight, shall we close it or leave for crash stats to tell the tale in 48 hours?

Comment 13

[Mike Shaver (:shaver emeritus)]

The graph in https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0b12pre&version=Firefox%3A4.0b11pre&version=Firefox%3A4.0b11&query_search=signature&query_type=exact&query=nsGenericElement%3A%3AGetPrimaryFrame%28mozFlushType%29&date=02%2F18%2F2011%2016%3A14%3A49&range_value=3&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsGenericElement%3A%3AGetPrimaryFrame%28mozFlushType%29 shows that it was a one-hit wonder.