Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Crash in exn_trace [@ js::Shape::trace(JSTracer*) ][@ js::Shape::trace ] mainly with TestPilot 1.1 and below

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
7 years ago
6 years ago

People

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

Tracking

({crash, regression, topcrash})

Trunk
crash, regression, topcrash
Points:
---

Firefox Tracking Flags

(blocking2.0 Macaw+, status2.0 .1-fixed, status1.9.2 unaffected, status1.9.1 unaffected)

Details

(Whiteboard: [sg:critical?][fx4-rc-ridealong], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Build : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100930 Firefox/4.0b7pre

This is a new crash signature that was introduced by b7pre/20100929 build.
It happens only under Windows XP.
It is #20 top crasher for b7pre/20100930 build.

Signature	js::Shape::trace(JSTracer*)
UUID	61d6d1b5-c6bf-4cff-be12-4c65d2100930
Time 	2010-09-30 22:43:46.779302
Uptime	30
Last Crash	36 seconds before submission
Install Age	52464 seconds (14.6 hours) since version was first installed.
Product	Firefox
Version	4.0b7pre
Build ID	20100930041305
Branch	2.0
OS	Windows NT
OS Version	5.1.2600 Service Pack 2
CPU	x86
CPU Info	GenuineIntel family 15 model 6 stepping 4
Crash Reason	EXCEPTION_ACCESS_VIOLATION_WRITE
Crash Address	0x1e
App Notes 	AdapterVendorID: 8086, AdapterDeviceID: 29c2

Frame 	Module 	Signature [Expand] 	Source
0 	mozjs.dll 	js::Shape::trace 	js/src/jsscope.cpp:1358
1 	mozjs.dll 	fun_trace 	js/src/jsfun.cpp:2075
2 	mozjs.dll 	js_TraceObject 	js/src/jsobj.cpp:6168
3 	mozjs.dll 	js::gc::MarkChildren 	js/src/jsgcinlines.h:199
4 	mozjs.dll 	js::gc::MarkObject 	js/src/jsgcinlines.h:179
5 	mozjs.dll 	fun_trace 	js/src/jsfun.cpp:2060
6 	mozjs.dll 	js_TraceObject 	js/src/jsobj.cpp:6168

The regression range is :
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c257bfb8cad0&tochange=a60414d076b5

More reports at :
http://crash-stats.mozilla.com/report/list?product=Firefox&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=js%3A%3AShape%3A%3Atrace%28JSTracer*%29
(Reporter)

Comment 1

7 years ago
It is #23 top crasher on 4.0b8pre for the last 3 days.
blocking2.0: --- → ?

Updated

7 years ago
blocking2.0: ? → -
status2.0: --- → wanted
(Reporter)

Comment 2

7 years ago
It is #12 top crasher in 4.0b8 for the last week.
(Reporter)

Comment 3

7 years ago
It is #21 top crasher in 4.0b11.
(Reporter)

Comment 4

7 years ago
It is #11 top crasher in 4.0b12.
(Reporter)

Comment 5

7 years ago
Here are some comments:
"playing universal war( 3 tabs required ) and blood wars"
"i don't know. i have closed the monitor and went to sleep. this morning found the crash report window."
"Escrevendo um e-mail no gmail.com"
Keywords: topcrash
Summary: crash on Windows XP [@ js::Shape::trace(JSTracer*) ] → Crash [@ js::Shape::trace(JSTracer*) ]

Comment 6

6 years ago
Interesting that this signature seems to have climbed in early FF4 returns. It has been the #2 browser crash for the past couple of days. We will watch this one and see what happens as the # of users climb.

Comment 7

6 years ago
This spiked very significantly on FF4 release day (yesterday), together with bug 615098 and bug 643746 (all three are in JS and started spiking on 4.0* the day before, so at least the spike cause might be related), which together account for 2800 crashes in a million 4.0* ADU on that day or about 7.4% of all 4.0* crashes on that day, all three are in the top ten top crashers for 4.0* for this day.

Comment 8

6 years ago
93% of these crashes have testpilot installed, while the average is at 32%, not sure if this correlation is coincidence or not.
(Reporter)

Updated

6 years ago
Summary: Crash [@ js::Shape::trace(JSTracer*) ] → Crash [@ js::Shape::trace(JSTracer*) ] mainly with TestPilot 1.1 and below
I just got hit by this today when clicking check boxes on a survey page.

Isn't Test Pilot installed in Firefox 4 by default so wouldn't most people have Test Pilot installed after upgrading to Firefox 4?

Comment 10

6 years ago
(In reply to comment #9)
> Isn't Test Pilot installed in Firefox 4 by default so wouldn't most people have
> Test Pilot installed after upgrading to Firefox 4?

It was part of the product in betas, but not in final. So everyone that had the beta will have it installed but everyone who only got final hasn't (unless they installed it manually).
(In reply to comment #10)
> It was part of the product in betas, but not in final. So everyone that had the
> beta will have it installed but everyone who only got final hasn't (unless they
> installed it manually).

Ah okay.  Strangely enough I got another of these crashes.  That's two in one day, when I've never seen it before today.  

bp-92beee74-1e16-4f34-8c47-04aca2110324

Comment 12

6 years ago
(In reply to comment #11)
> Ah okay.  Strangely enough I got another of these crashes.  That's two in one
> day, when I've never seen it before today.  
> 
> bp-92beee74-1e16-4f34-8c47-04aca2110324

We are currently unsure what causes this, but we need to get some tracking on it. You also appear to have testpilot activated, which right now is our only (weak) clue.

Comment 13

6 years ago
jono, any updates or thoughts from looking at test pilot side?

dmaindelin, any ideas on how to mitigate the crash on the JS side, or help in understanding what addons might be doing?
Bill, Luke, and I were talking about this morning. We think it may be due to a compartment mismatch. An exception object keeps a list of argument values from the JS stack frames live at the point of the exception. The argument values may belong to different compartments from the exception, but they are not wrapped, which seems like a bug.
(Assignee)

Comment 16

6 years ago
Woohoo, the assert hits, only when I install test pilot, and then the offending frame's script is indeed resource://testpilot/modules/lib/securable-module.js -> resource://testpilot/modules/lib/memory.js.
Group: core-security
(Assignee)

Comment 17

6 years ago
Created attachment 521956 [details] [diff] [review]
patch

The fix is simple.
Assignee: general → luke
Status: NEW → ASSIGNED
Attachment #521956 - Flags: review?(gal)

Comment 18

6 years ago
Wow, sounds like that was some impressive detective work figuring out the cause of the crash.

Judging by Luke's patch, it seems like this has to be fixed in the core, and so there isn't anything that needs to change in Test Pilot, is that correct?
(Assignee)

Comment 19

6 years ago
Correct; Test Pilot just tickled the dragon.

Comment 20

6 years ago
topcrash + security risk?  means it really needs to get out in 4.0.1

marked this as ride-along to get on the radar since I'm not quite sure how to mark this kinds of thinks that should have blocked RC if we had known about them earlier.

what's the sg: rating?
blocking2.0: - → ?
Whiteboard: [fx4-rc-ridealong]

Comment 21

6 years ago
Comment on attachment 521956 [details] [diff] [review]
patch

If the current compartment is privileged (chrome), it might be allow to see the content frame. Maybe we should do a follow-up and copy data into the destination compartment in that case.
Attachment #521956 - Flags: review?(gal) → review+
(Assignee)

Comment 22

6 years ago
http://hg.mozilla.org/mozilla-central/rev/9be05c62b6ce

If nightlies show a good reduction in this crash (and/or bug 615098, bug 615098), should this land on the 2.0?
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 23

6 years ago
looks like the volume on mozilla-central / 4.0 "pre" releases is extremely low (like 0-2 crashes per day).  so we might need a beta or final release to really know how much impact the fix might have.

for example, here is the volume of crashes per release version in crash data that we got yesterday.

20110324 9309 total crashes

date     total    breakdown by build
                  count build, count build, ...

                 	8487 4.02011031805, 
        		412 4.0b122011022221, 	331 4.02011030319, 
        		20 4.0b102011012116, 	14 4.0b112011020314, 
        		8 4.2a1pre2011032316, 	7 4.0b92011011019, 
        		7 4.0b13pre2011032203, 	6 4.0b82010121417, 
        		3 4.0b72010110414, 	3 4.0b13pre2011032103, 
        		3 4.02011031716, 	2 4.2a1pre2011032314, 
        		2 4.2a1pre2011032307, 	2 4.0b13pre2011032303, 
        		1 4.2a1pre2011032403, 	1 4.0b13pre2011032003,
(Assignee)

Comment 24

6 years ago
Oops, comment 22 clearly did not see comment 20.
(Reporter)

Updated

6 years ago
OS: Windows XP → All
Hardware: x86 → All
Summary: Crash [@ js::Shape::trace(JSTracer*) ] mainly with TestPilot 1.1 and below → Crash [@ js::Shape::trace(JSTracer*) ][@ js::Shape::trace ] mainly with TestPilot 1.1 and below
blocking2.0: ? → .x+
Guessing a missing compartment check might be sg:high, but that's just a guess. Would it allow content/chrome mixing?
blocking2.0: .x+ → Macaw
Whiteboard: [fx4-rc-ridealong] → [sg:high][fx4-rc-ridealong]
(Assignee)

Comment 26

6 years ago
The pre-existing security check in stack walking should prevent cross-origin mixing from happening directly.  However, we are still accessing trash memory, so it seems to be in the theoretically-possible-to-exploit category.
because it's completely unclear, "blocking2.0: Macaw" means we want this fix on the mozilla2.0 repository for the 4.0.1 release. Consider that repo equivalent to the end-game Fx4 release and request explicit approval2.0 on the appropriate patch.
Whiteboard: [sg:high][fx4-rc-ridealong] → [sg:critical?][fx4-rc-ridealong]
Comment on attachment 521956 [details] [diff] [review]
patch

Approved for landing on mozilla2.0, a=dveditz for release-drivers

forgive the previous boilerplate comment
Attachment #521956 - Flags: approval2.0+
(Assignee)

Comment 29

6 years ago
http://hg.mozilla.org/releases/mozilla-2.0/rev/cbda245a805d

Updated

6 years ago
status2.0: wanted → .1-fixed

Comment 30

6 years ago
We don't see this signature on branches, marking unaffected for now.
status1.9.1: --- → unaffected
status1.9.2: --- → unaffected
(Reporter)

Comment 31

6 years ago
It is #9 top crasher in 4.0.1, so I reopen this bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 32

6 years ago
I think it might be better to file another one for the remaining things, unless you know that the patch in here doesn't fix any of the crashes we've been seeing with this. Real work has been done here, and the cause supposed to be fixed by the patches in here was deemed a security risk. This bug should cover that class of crashes fixed by this patch. A new bug should be filed for any other class of crashes that might result in the same signature.
(Reporter)

Comment 33

6 years ago
As it became from #2 to #9 top crasher, the patch has fixed some causes. They should be written in the summary, so that the bug isn't confused with the meta bug.
(Reporter)

Updated

6 years ago
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
Summary: Crash [@ js::Shape::trace(JSTracer*) ][@ js::Shape::trace ] mainly with TestPilot 1.1 and below → Crash in exn_trace [@ js::Shape::trace(JSTracer*) ][@ js::Shape::trace ] mainly with TestPilot 1.1 and below

Comment 34

6 years ago
When is this fix going to be available? These crashes are tedious.
(In reply to comment #34)
> When is this fix going to be available? These crashes are tedious.

It should be fixed in 4.0.1. The fix is only for crashes with exn_trace in the stack trace.

Comment 36

6 years ago
Fine. When is 4.0.1 going to be available. I crashed again.
(Reporter)

Updated

6 years ago
Blocks: 653081
Group: core-security
Crash Signature: [@ js::Shape::trace(JSTracer*) ] [@ js::Shape::trace ]
You need to log in before you can comment on or make changes to this bug.