Closed Bug 645775 Opened 13 years ago Closed 13 years ago

Firefox 4.2a1pre Crash [@ JSObject::isXML() ]

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
5 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox5 - ---

People

(Reporter: marcia, Assigned: dmandelin)

Details

(Keywords: crash, regression, reproducible, Whiteboard: [It is #6 top crasher in 6.0.])

Crash Data

Seen while reviewing trunk crash data. http://tinyurl.com/4dosv8g links to the crashes which are all Windows.

https://crash-stats.mozilla.com/report/index/83d231fe-94cc-4156-b6f6-9232f2110328

Frame 	Module 	Signature [Expand] 	Source
0 	mozjs.dll 	JSObject::isXML 	js/src/jsxml.h:235
1 	mozjs.dll 	js::mjit::stubs::Add 	
2 	mozjs.dll 	js::mjit::ic::GetGlobalName 	js/src/methodjit/MonoIC.cpp:111
3 	mozcrt19.dll 	malloc 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:5882
4 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4782
5 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:653
6 	mozjs.dll 	js::Execute 	js/src/jsinterp.cpp:1028
7 	mozjs.dll 	EvaluateUCScriptForPrincipalsCommon 	js/src/jsapi.cpp:5059
8 	mozjs.dll 	JS_EvaluateUCScriptForPrincipalsVersion 	js/src/jsapi.cpp:5075
9 	xul.dll 	nsJSContext::EvaluateString 	dom/base/nsJSEnvironment.cpp:1460
We NPE here:

    if (lval.isObject() && lval.toObject().isXML() &&
        rval.isObject() && rval.toObject().isXML()) {

Looks like one of those "null tagged as object" situations.
Several that I checked had URLs here:

  http://chutecerto.globo.com/home/ver/ 

I went there and clicked a few times, but nothing happened. Marcia, do you think you could try to repro this a bit? Or maybe we could use BugHunter?

Alternatively, we could try to get back the source location of the crash and see if we can spot the problem.
I tried that site a few times in the lab, will try again. Adding bc to the bug for the Bughunter piece.

(In reply to comment #2)
> Several that I checked had URLs here:
> 
>   http://chutecerto.globo.com/home/ver/ 
> 
> I went there and clicked a few times, but nothing happened. Marcia, do you
> think you could try to repro this a bit? Or maybe we could use BugHunter?
> 
> Alternatively, we could try to get back the source location of the crash and
> see if we can spot the problem.
I've been testing the full set of 4.0 crash urls since the release and am now working through 3-24/25. This signature has been seen a number of times in the crash dumps. One in particular was in an extension 7B707db484-2428-402d-afb5-d85b387544c7 (mario_forever?) with a latin profile name. Many in the chutecerto.globo.com site. Perhaps these are all the same person?

I have not seen this particular signature as of yet. I just submitted 84 urls to be retested and we'll see what happens.

Marcia, can you check out the extension ?
I installed the extension on the Win XP machine in the lab - it is another one of those toolbars that has conduit as part of the install - http://marioforever.ourtoolbar.com/. These "community" toolbars all tend to look the same but with different branding.

Several attempts at loading the URL so far have not met with success.
chofmann maybe you can some more URLs for this one?
checking --- JSObject::isXML.. 20110328-crashdata.csv
found in: 4.2a1pre 4.0b13pre
release total-crashes
              JSObject::isXML.. crashes
                         pct.
all     792304  20      2.52428e-05
4.2a1pre        1026    14      0.0136452
4.0b13pre       309     6       0.0194175

Correlation to startup or time of session
20 total crashes for JSObject::isXML.. on 20110328-crashdata.csv
7 startup crashes inside 30 sec.
12 startup crashes inside 3 min.
10 repeated crashes inside 3 min. of last crash

os breakdown
JSObject::isXML..Total 20
Win5.1  0.60
Win6.0  0.00
Win6.1  0.40

urls for testing  are all on globo.com --- looks like you might have to get past login.  also gmail running for good measure.

   3 http://chutecerto.globo.com/home/ver
   2 http://chutecerto.globo.com/home/ver/
   2 about:blank
   1 wyciwyg://4/http://talkgadget.google.com/talkgadget/mole?id=g ,.,,
   1 http://chutecerto.globo.com/ranking/ver/bolao/10952/
   1 http://chutecerto.globo.com/palpites/ver/
   3 http://chutecerto.globo.com/login/valida/GLBID ,,,
None of the 84 urls I ran through the automation crashed on winxp/win7/mac 10.5/fedora14. I'm spidering chutecerto 2 levels deep on winxp at the moment and have not crashed after 2228 urls.
It is #5 top crasher in 4.0b2.

STR:
* Go to http://www.yellowpages.com/montain-view-ca/mozilla?g=montain+view%2C+ca
* Click the map on the right
* Boom!
tracking-firefox5: --- → ?
Keywords: reproducible
https://crash-stats.mozilla.com/report/list?signature=JSObject::isXML%28%29 indicates 521 crashes in the last week. Can we get this assigned to someone to look out now that we have a reproducible site (Comment 9)?
Assignee: general → dmandelin
I forgot to add in Comment 10 that I reproduced this using Windows 7 with the latest trunk build. I was not able to repro on Mac with the same build.
This is definitely a regression since 4.0.
Comment 2 is private: false
Comment 3 is private: false
Comment 4 is private: false
every few days we see this on old 4.x betas or before, but this is also a significant regression in 5.0

         JSObject::isXML..
date     total    breakdown by build
         crashes  count build, count build, ...

20110520 62  	14 5.0a22011051904, 
        		11 6.0a12011051903, 	11 5.0a22011052004, 
        		8 5.02011042714, 	6 5.02011051719, 
        		3 5.0a22011051704, 	3 5.0a22011042904, 
        		3 4.2a1pre2011041203, 	1 6.0a12011052003, 
        		1 5.0a22011051804, 	1 5.0a22011051604, 
20110521 46  	27 5.02011051719, 
        		7 5.02011042714, 	4 6.0a12011052103, 
        		3 5.0a22011052104, 	3 4.0b13pre2011032203, 
        		1 6.0a12011052003, 	1 5.0a22011052004, 
20110522 50  	34 5.02011051719, 
        		9 5.02011042714, 	2 6.0a12011050503, 
        		2 5.0a22011051904, 	1 6.0a12011052203, 
        		1 6.0a12011052003, 	1 6.0a12011051803, 
20110523 51  	43 5.02011051719, 
        		3 5.0a22011052304, 	2 5.0a22011052204, 
        		1 6.0a12011052203, 	1 5.02011042714, 
        		1 4.0b22010072019, 
20110524 165  	132 5.02011051719, 
        		8 6.0a12011052403, 	7 6.0a12011052303, 
        		7 5.0a22011052404, 	4 5.02011042714, 
        		2 5.0a22011051904, 	1 6.0a12011052203, 
        		1 6.0a12011051403, 	1 5.0a22011052304, 
        		1 5.0a22011052204, 	1 4.2a1pre2011041103,
The reproducible version of this bisects to the same range as the repro test case in bug 605033. See bug 605033 comment 24. The short story is that it is probably due to PGO.
Keywords: regression
Version: Trunk → 5 Branch
Does the patch in bug 605033 fix it?
(In reply to comment #15)
> Does the patch in bug 605033 fix it?

The reproducible test case here now works OK in nightly builds. I guess we need to see what happens in the new beta to see if it helps with the topcrash--nightly doesn't have enough data.
already dealt with this with PGO disable, we believe.
tracking-firefox5: ? → -
volume is going down in general and don't see any significant counts from the 5.0 beta builds from 2011 05 27 with a significant number users on those builds now.


         JSObject::isXML..
date     total    breakdown by build
         crashes  count build, count build, ...

20110601 474  	443 5.02011051719, 
        		14 6.0a22011053104, 	5 6.0a22011060104, 
        		4 5.0a22011052404, 	2 6.0a22011053004, 
        		2 6.0a12011052103, 	2 6.0a12011050803, 
        		1 5.0a22011052204, 	1 5.02011042714, 
20110602 395  	370 5.02011051719, 
        		7 6.0a22011060204, 	6 6.0a22011060104, 
        		5 6.0a22011053104, 	4 5.0a22011052404, 
        		2 5.0a22011051304, 	1 6.0a12011052203, 
20110603 202  	192 5.02011051719, 
        		5 5.0a22011052404, 	3 6.0a22011060204, 
        		1 6.0a22011053104, 	1 5.02011042714, 
20110604 164  	150 5.02011051719, 
        		3 6.0a22011060304, 	3 6.0a12011052203, 
        		2 6.0a22011060404, 	2 6.0a12011051003, 
        		1 6.0a12011052303, 	1 5.0a22011052404, 
        		1 5.0a22011043004, 	1 5.02011042714, 
20110605 84  	79 5.02011051719, 
        		2 6.0a22011060404, 	1 5.0a22011052404, 
        		1 5.02011042714, 	1 4.2a1pre2011041203, 
20110606 160  	142 5.02011051719, 
        		5 6.0a22011060504, 	3 6.0a22011060204, 
        		3 5.0a22011052404, 	2 5.0a22011052304, 
        		2 5.02011042714, 	1 6.0a22011060304, 
        		1 6.0a12011052403, 	1 5.0a22011052004,
Crash Signature: [@ JSObject::isXML() ]
It is #6 top crasher in 6.0.
I can still reproduce with STR in comment 9.
tracking-firefox6: --- → ?
This is related to turning off JS PGO...we need to track these.
tracking-firefox6: ? → +
We're getting pretty deep into Firefox 6 Beta. If something's going to happen for this bug, it's going to need to happen soon.
Whiteboard: [It is #6 top crasher in 6.0.]
This went down when we turned off PGO. 6.0b1 it was in the top 10, for 6.0b2 it's around #100. Removing the tracking flag.
tracking-firefox6: + → ---
This signature only has 14 crashes in the last week. Per triage session, marking as WFM.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.