Closed
Bug 604588
Opened 14 years ago
Closed 14 years ago
crash [@ JSStackFrame::script() ]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta7+ |
People
(Reporter: scoobidiver, Assigned: dvander)
Details
(Keywords: crash, regression)
Crash Data
Build: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre This is a new crash signature. Crashes first appeared on 10/14th/10 at 4:21 in b8pre/20101013 build, that is almost one day after the release of this build. So it can be caused by: * an external update: MS patch tuesday (17 patches), java 1.6.22 update, extension update... * or by the build itself. If it is caused by the build, here is the regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2593c8c8af8b&tochange=f6e81dd5a125 Signature JSStackFrame::script() UUID 9a935cd4-93d4-497f-8006-0e3aa2101014 Time 2010-10-14 22:31:37.11801 Uptime 2387 Last Crash 2389 seconds (39.8 minutes) before submission Install Age 4454 seconds (1.2 hours) since version was first installed. Product Firefox Version 4.0b8pre Build ID 20101014041748 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 0x0 App Notes AdapterVendorID: 8086, AdapterDeviceID: 29c2 Frame Module Signature [Expand] Source 0 mozjs.dll JSStackFrame::script js/src/jsinterp.h:267 1 mozjs.dll js::Interpret js/src/jsinterp.cpp:2787 2 mozjs.dll FinishExcessFrames js/src/methodjit/InvokeHelpers.cpp:737 3 mozjs.dll RunTracer js/src/methodjit/InvokeHelpers.cpp:873 4 mozjs.dll js::mjit::stubs::InvokeTracer js/src/methodjit/InvokeHelpers.cpp:917 5 mozjs.dll js::mjit::EnterMethodJIT js/src/methodjit/MethodJIT.cpp:742 6 mozjs.dll CheckStackAndEnterMethodJIT js/src/methodjit/MethodJIT.cpp:767 7 mozjs.dll js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:784 8 mozjs.dll js::RunScript js/src/jsinterp.cpp:635 9 mozjs.dll js::Invoke js/src/jsinterp.cpp:747 10 mozjs.dll js_fun_apply js/src/jsfun.cpp:2369 11 @0x15262b00 12 mozjs.dll js::mjit::EnterMethodJIT js/src/methodjit/MethodJIT.cpp:742 13 mozjs.dll CheckStackAndEnterMethodJIT js/src/methodjit/MethodJIT.cpp:767 14 mozjs.dll js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:784 15 mozjs.dll js::RunScript js/src/jsinterp.cpp:635 16 mozjs.dll js::Invoke js/src/jsinterp.cpp:747 17 mozjs.dll js_fun_apply js/src/jsfun.cpp:2369 18 @0x15262b00 19 mozjs.dll js::mjit::EnterMethodJIT js/src/methodjit/MethodJIT.cpp:742 20 mozjs.dll CheckStackAndEnterMethodJIT js/src/methodjit/MethodJIT.cpp:767 21 mozjs.dll js::mjit::JaegerShot js/src/methodjit/MethodJIT.cpp:784 22 mozjs.dll js::RunScript js/src/jsinterp.cpp:635 23 mozjs.dll js::Invoke js/src/jsinterp.cpp:747 24 mozjs.dll js::ExternalInvoke js/src/jsinterp.cpp:871 25 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:4961 26 xul.dll nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1692 27 xul.dll nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:571 28 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114 29 xul.dll SharedStub xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141 30 xul.dll nsDOMEventListenerWrapper::HandleEvent content/events/src/nsDOMEventTargetHelper.cpp:65 31 xul.dll nsEventListenerManager::HandleEventSubType content/events/src/nsEventListenerManager.cpp:1112 More reports at: http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=JSStackFrame%3A%3Ascript%28%29&version=Firefox%3A4.0b8pre#modver
Reporter | ||
Comment 1•14 years ago
|
||
It is #13 top crasher in b8pre for the last week.
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 2•14 years ago
|
||
#5 topcrash on the trunk yesterday is probably a better reflection of where this is going. first appeared yesterday on oct 14, in builds from oct 13 and 14. this should probably block 4.0b7 if the change is headed for that branch too. date tl crashes at, count build, count build, ... JSStackFrame::script.. 20101012 20101013 20101014 103 88 4.0b8pre2010101404, 15 4.0b8pre2010101322,
Comment 3•14 years ago
|
||
This looks like a tracer integration bug (all reports have stack traces like comment 0). This part was rewritten in bug 603044; should probably wait for that to land on mozilla-central.
Updated•14 years ago
|
blocking2.0: ? → beta7+
Comment 4•14 years ago
|
||
There are no JS engine changes in the regression range. There may have been a change to some JS that runs as content (so that methodjit is on) that exposed a bug.
Comment 5•14 years ago
|
||
(In reply to comment #4) > There are no JS engine changes in the regression range. There may have been a > change to some JS that runs as content (so that methodjit is on) that exposed a > bug. One problem might be that our version IDs are the same for builds from the TM repository. I've noticed this before, but keep forgetting to file a bug on it.
Comment 6•14 years ago
|
||
Historical analysis: Aside from a lone report from a 9/23 build, this started with the 10/13 build, with 25 crashes on that day, but became 6-8x more common on 10/14 and afterward. Reasons why a spike like that could happen: 1. Something landed on TM for 10/13, got a hit a few times that day, then made it to m-c on 10/14 and started getting more hits. 2. Something busted it for 10/13, and another patch made it worse on 10/14. 3. Not many people tested the 10/13 build, many more got later builds. Another interesting observation: Looking at the topcrashes on Socorro, it looks like xpconnect/compartments-related crashes had the same pattern: appear (or grow) on 10/13, grow (or grow again) on 10/14, while other types of crashes, and the crashes/ADU, did not show this. This makes #3 seem unlikely. As noted in comment 4, nothing JS hit m-c on 10/12 (which would show up on 10/13), which makes #2 less likely. *** #1 would seem particularly likely if m-c had 6-8x the ADUs that TM does. Does anyone know if that's true? If it is #1, then it seems like it's basically compartments, but especially likely to be a patch that hit TM on 10/12 (for the 10/13 build), which would have hit m-c for the 10/14 build: http://hg.mozilla.org/tracemonkey/pushloghtml?startdate=10%2F11%2F2010&enddate=10%2F12%2F2010 Nothing there looks pretty likely to me, though. And this could still be just a trace integration bug that was exposed by compartments.
Comment 7•14 years ago
|
||
At least 3 of the report comments indicate the user was doing some routing in maps.google.com when they crashed, but I haven't yet been able to repro.
Updated•14 years ago
|
Assignee: general → dvander
Comment 8•14 years ago
|
||
I don't see any with buildids later than Oct 20, I think there was merge that day that may have fixed this.
Comment 9•14 years ago
|
||
Going to WFM this bug, but if we see more reports please reopen.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
Crash Signature: [@ JSStackFrame::script() ]
You need to log in
before you can comment on or make changes to this bug.
Description
•