Closed Bug 630957 Opened 15 years ago Closed 15 years ago

Firefox 4.0b11pre Crash [@ nsGenericElement::GetChildrenList ] with Firebug 1.7X and below

Categories

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

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: marcia, Assigned: jst)

References

Details

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

Crash Data

Seen while reviewing crash stats. Currently a low volume Mac only crash. http://tinyurl.com/4zte7r5 to the crash reports. There is only one comment which mentions "resizing." Crashes started showing up using the 2011013000 build. Possible pushlog regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=94a51a3b64d4&tochange=336d5906cb0f Frame Module Signature [Expand] Source 0 XUL nsGenericElement::GetChildrenList nsINode.h:1164 1 XUL nsNSElementTearoff::GetChildElementCount content/base/src/nsGenericElement.h:724 2 XUL NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:208 3 XUL XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:3071 4 XUL XPC_WN_GetterSetter js/src/xpconnect/src/xpcprivate.h:2643 5 XUL js::Invoke js/src/jscntxtinlines.h:697 6 XUL js::ExternalInvoke js/src/jsinterp.cpp:858 7 XUL js::ExternalGetOrSet js/src/jsinterp.h:961 8 XUL js::JSProxyHandler::get js/src/jsproxy.cpp:131 9 XUL xpc::XrayWrapper<JSCrossCompartmentWrapper>::get js/src/xpconnect/wrappers/XrayWrapper.cpp:756 10 XUL js::proxy_GetProperty js/src/jsproxy.cpp:787 11 XUL js::Interpret js/src/jsobj.h:1194 12 XUL js::Invoke js/src/jsinterp.cpp:657 13 XUL js_fun_call js/src/jsfun.cpp:2116 14 XUL js_fun_apply js/src/jsfun.cpp:2146 15 XUL js::Interpret js/src/jscntxtinlines.h:697 16 XUL js::Invoke js/src/jsinterp.cpp:657 17 XUL js::ExternalInvoke js/src/jsinterp.cpp:858 18 XUL JS_CallFunctionValue js/src/jsinterp.h:961 19 XUL nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:2008 20 XUL nsGlobalWindow::RunTimeout dom/base/nsGlobalWindow.cpp:9087 21 XUL nsGlobalWindow::TimerCallback dom/base/nsGlobalWindow.cpp:9432 22 XUL nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:425 23 XUL nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:517 24 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:633 25 XUL NS_ProcessPendingEvents_P nsThreadUtils.cpp:200 26 XUL nsBaseAppShell::NativeEventCallback widget/src/xpwidgets/nsBaseAppShell.cpp:132 27 XUL nsAppShell::ProcessGeckoEvents widget/src/cocoa/nsAppShell.mm:399 28 CoreFoundation CoreFoundation@0x4e400 29 CoreFoundation CoreFoundation@0x4c5f8
This is another tearoff with null mContent, just like bug 630877.
Depends on: 630877
And with the same regression range.
Depends on: 614347
This is the top crash not caused by an extension for Firefox 4 beta 11 on Mac OS X.
It is #2 top crasher on Mac OS X in 4.0b11. Here are extension correlations: nsGenericElement::GetChildrenList|EXC_BAD_ACCESS / KERN_INVALID_ADDRESS (61 crashes) 100% (61/61) vs. 22% (187/847) firebug@software.joehewitt.com (Firebug, https://addons.mozilla.org/addon/1843) 3% (2/61) vs. 2% (16/847) 1.6.1 5% (3/61) vs. 2% (16/847) 1.6.2 2% (1/61) vs. 0% (3/847) 1.6X.0b1 90% (55/61) vs. 16% (136/847) 1.7X.0a9
blocking2.0: --- → ?
Keywords: topcrash
Summary: Firefox 4.0b11pre Crash [@ nsGenericElement::GetChildrenList ] → Firefox 4.0b11pre Crash [@ nsGenericElement::GetChildrenList ] with Firebug 1.7X and below
Blocking, but this should be fixed by bug 614347.
blocking2.0: ? → final+
Whiteboard: [hardblocker]
Whiteboard: [hardblocker] → [hardblocker][potential fix in bug 614347]
Assignee: nobody → jst
Bug 614347 landed tonight, shall we close it or leave for crash stats to tell the tale in 48 hours?
I'd say close and continue to watch crash-stats. we might need to get the fix out in a beta to see conclusively the effects of bug 614377 on this signature. weekday volume on mozilla-central builds is only 1-6 crashes per day. volume is low on the weekends and crashes only seem to show up in beta builds during that time, so it might take a bit longer than 48 hours to see the effects in crash data. nsGenericElement::GetChildrenList date total breakdown by build crashes count build, count build, ... 20110212 29 4.0b112011020314 20110213 33 32 4.0b112011020314, 1 4.0b12pre2011021203, 20110214 108 98 4.0b112011020314, 6 4.0b12pre2011021303, 2 4.0b12pre2011021403, 2 4.0b12pre2011021103, 20110215 92 78 4.0b112011020314, 6 4.0b12pre2011021503, 5 4.0b12pre2011021303, 2 4.0b12pre2011021403, 1 4.0b12pre2011021003,
I see no reports since the 16th, though the table/graph at http://bit.ly/g5Dgqu doesn't show the same numbers as chofmann's even for those dates?
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
yeah, this looks fixed in post builds post 20110216030352 . If I sort the table/graph in comment 8 on version I see 14 crashes for various 4.0b12pre builds on feb15. the numbers in commment 7 show 14 crashes for 4.0b12pre on feb15 too.
Crash Signature: [@ nsGenericElement::GetChildrenList ]
You need to log in before you can comment on or make changes to this bug.