Crash [@ nsGenericElement::GetPrimaryFrame(mozFlushType) ]

RESOLVED FIXED

Status

()

Core
DOM
--
critical
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: Scoobidiver (away), Assigned: smaug)

Tracking

({crash, regression})

Trunk
x86
Windows 7
crash, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [hardblocker][potential fix in bug 614347], crash signature)

(Reporter)

Description

8 years ago
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
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....
Even ccing Peter.
And how are we landing in nsNSElementTearoff::GetBoundingClientRect anyway?  This should be quickstubbed, no?  That worries me....
status2.0: --- → ?
We should, but could be that the quickstub was removed from the prototype?
Hmm.  Possible, I suppose.

But I still don't see how mContent could be null there.
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.
Or that we unlinked but then didn't GC and the JS reflection is still around?  Bug 624549 is in the regression range...
Blocks: 624549
This looks like the other bugs I'm hoping bug 614347 will fix.
blocking2.0: --- → ?
status2.0: ? → ---

Updated

8 years ago
Duplicate of this bug: 631478
(Reporter)

Updated

8 years ago
No longer blocks: 631478
blocking2.0: ? → final+
Whiteboard: [hardblocker]
Need an owner here immediately.
This depends on bug 614347. That should fix the problem with tearoff objects and
unlinking.
Whiteboard: [hardblocker] → [hardblocker][potential fix in bug 614347]

Updated

8 years ago
Assignee: nobody → Olli.Pettay
Bug 614347 landed tonight, shall we close it or leave for crash stats to tell the tale in 48 hours?
Crash Signature: [@ nsGenericElement::GetPrimaryFrame(mozFlushType) ]
You need to log in before you can comment on or make changes to this bug.