Closed Bug 604588 Opened 14 years ago Closed 14 years ago

crash [@ JSStackFrame::script() ]

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
critical

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
It is #13 top crasher in b8pre for the last week.
blocking2.0: --- → ?
#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,
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.
blocking2.0: ? → beta7+
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.
(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.
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.
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.
Assignee: general → dvander
I don't see any with buildids later than Oct 20, I think there was merge that day that may have fixed this.
Going to WFM this bug, but if we see more reports please reopen.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ JSStackFrame::script() ]
You need to log in before you can comment on or make changes to this bug.