481060 - Assertion: "tree->root == tree" and crash while loading a website [@ JS_GetMethodById][@ js_Blacklist]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090302 Minefield/3.2a1pre ID:20090302020439

Opening the "create new project" page on quality.mozilla.org crashes Minefield.

Crash report: bp-a6fc067e-85c5-4c7e-9bc3-2e4152090302

0  	libmozjs.dylib  	JS_GetMethodById  	 js/src/jsapi.cpp:3699
1 	libmozjs.dylib 	js_CallIteratorNext 	js/src/jsiter.cpp:610
2 	libmozjs.dylib 	js_Interpret 	js/src/jsinterp.cpp:3238
3 	libmozjs.dylib 	js_Invoke 	js/src/jsinterp.cpp:1330
4 	libmozjs.dylib 	js_fun_call 	js/src/jsfun.cpp:1654
5 	libmozjs.dylib 	js_Interpret 	js/src/jsinterp.cpp:5006
[...]

Steven, your tryserver build on bug 473467 also causes this on 1.9.1 branch for me. It doesn't happen with nightly builds. Minefield always crashes. So there is a patch which is checked into trunk right now and probably waits for 1.9.1 checkin. Probably tracemonkey?

I'll try to reduce the content to create a minimized testcase.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: Stack with gdb

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

#0  JS_Assert (s=0x36e024 "tree->root == tree", file=0x36dfd8 "/data/mozilla/build/mozilla-central/mozilla/js/src/jstracer.cpp", ln=459) at /data/mozilla/build/mozilla-central/mozilla/js/src/jsutil.cpp:62
#1  0x002e49f9 in js_Blacklist (tree=0x187d9960) at /data/mozilla/build/mozilla-central/mozilla/js/src/jstracer.cpp:459
#2  0x00308309 in TraceRecorder::closeLoop (this=0x18679540, tm=0x127ad03c, demote=@0xbfffa2df) at /data/mozilla/build/mozilla-central/mozilla/js/src/jstracer.cpp:2523
#3  0x003088a7 in js_CloseLoop (cx=0x1d186000) at /data/mozilla/build/mozilla-central/mozilla/js/src/jstracer.cpp:3519

I better mark this as blocking1.9.1 so we don't lose track. Will have to search for the regression range too.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #0)

> Steven, your tryserver build on bug 473467 also causes this on 1.9.1
> branch for me. It doesn't happen with nightly builds. Minefield
> always crashes. So there is a patch which is checked into trunk
> right now and probably waits for 1.9.1 checkin. Probably
> tracemonkey?

So my new mozilla-central tryserver build for bug 473467 doesn't
crash?

Once this bug has been figured out, I can make new tryserver builds
for bug 473467 ... if that's appropriate.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #3)
> So my new mozilla-central tryserver build for bug 473467 doesn't
> crash?

Also a normal nightly build still crashes. I don't need the tryserver build you made in bug 473467 to reproduce the crash.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Andreas, could it be a regression from your work on bug 479109?

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Oh, the trunk nightly from 09022802 works fine and I don't see the crash.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

For now I looks like it's a bit harder to get a simplified testcase. Saving the page locally doesn't crash the browser.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Definitely a regression from the patch on bug 479109. Is it a P1?

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I forgot to say that you have to login to QMO to see this crash. The latest nightly build on 1.9.1 also starts crashing now.

Comment 10

[Simon Bünzli]

I get a crash with at the same point over at http://map.search.ch/ (no login required). Might be easier to simplify...

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thanks Simon. It's good to have one website without login. But after saving to disk and loading locally it doesn't crash too. Probably it happens while loading the map.

Comment 12

[Tony Chung [:tchung]]

(In reply to comment #9)
> I forgot to say that you have to login to QMO to see this crash. The latest
> nightly build on 1.9.1 also starts crashing now.

I'm also crashing repeatedly on trunk and 191 branch trying to edit a post on QMO.

1.9.1: http://crash-stats.mozilla.com/report/index/30495825-b16b-41b5-8816-1b14c2090304
trunk: http://crash-stats.mozilla.com/report/index/6aec8b5f-0ff0-4a42-b5f5-cc9152090304
trunk: http://crash-stats.mozilla.com/report/index/54b0960d-efac-4347-ae02-5354c2090304

Comment 13

[Tony Chung [:tchung]]

Per whimboo on irc #shiretoko, this is also happening on the latest tracemonkey builds:

http://crash-stats.mozilla.com/report/pending/3b300f1e-36ea-4c2f-ad52-0c6f32090304

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2]]

For debug builds you will get an assertion which triggers this crash.

Comment 15

[Martijn Wargers (dead)]

Attachment: zipped up unminimized testcase

Comment 16

[Graydon Hoare :graydon]

Attachment: Fix the bug

Seems we were just being a bit too optimistic that the blacklisted fragment was always the tree root; assumption doesn't hold when we encounter a blacklisting condition on a branch. Fix is pretty trivial: pass the roots in all cases, explicitly.

Tested on alexa top 100 global, works fine. No regression on sunspider, passes trace-test.

Comment 17

[Graydon Hoare :graydon]

(er, also works on the provided testcase, naturally; thanks for that!)

Comment 18

[Andreas Gal :gal]

Comment on attachment 365513 [details] [diff] [review]
Fix the bug

>Assertion: "tree->root == tree" and crash while loading a website.
>
>diff -r 744c494713e4 js/src/jstracer.cpp
>--- a/js/src/jstracer.cpp	Wed Mar 04 09:12:22 2009 -0600
>+++ b/js/src/jstracer.cpp	Wed Mar 04 12:45:28 2009 -0800
>@@ -2458,7 +2458,7 @@
>     Fragmento* fragmento = tm->fragmento;
>     if (treeInfo->maxNativeStackSlots >= MAX_NATIVE_STACK_SLOTS) {
>         debug_only_v(printf("Blacklist: excessive stack use.\n"));
>-        js_Blacklist(fragment);
>+        js_Blacklist(fragment->root);
>         return;
>     }
>     if (anchor && anchor->exitType != CASE_EXIT)
>@@ -2472,7 +2472,7 @@
>         return;
>     if (fragmento->assm()->error() != nanojit::None) {
>         debug_only_v(printf("Blacklisted: error during compilation\n");)
>-        js_Blacklist(fragment);
>+        js_Blacklist(fragment->root);
>         return;
>     }
>     if (anchor) {
>@@ -2536,7 +2536,7 @@
> 
>     if (callDepth != 0) {
>         debug_only_v(printf("Blacklisted: stack depth mismatch, possible recursion.\n");)
>-        js_Blacklist(fragment);
>+        js_Blacklist(fragment->root);
>         trashSelf = true;
>         return false;
>     }
>@@ -2717,7 +2717,7 @@
> 
>     if (callDepth != 0) {
>         debug_only_v(printf("Blacklisted: stack depth mismatch, possible recursion.\n");)
>-        js_Blacklist(fragment);
>+        js_Blacklist(fragment->root);
>         trashSelf = true;
>         return;
>     }
>@@ -4270,7 +4270,7 @@
>         /* If we hit the max peers ceiling, don't try to lookup fragments all the time. Thats
>            expensive. This must be a rather type-unstable loop. */
>         debug_only_v(printf("Blacklisted: too many peer trees.\n");)
>-        js_Blacklist(f);
>+        js_Blacklist(f->root);

I believe f is always a root here, so you might drop the ->root here. otoh it can't hurt, since for root fragments f->root == f.

>         return false;
>     }
>

Comment 19

[Graydon Hoare :graydon]

http://hg.mozilla.org/tracemonkey/rev/7cd904a49d37

Comment 20

[mdew]

will this make it into beta3?

Comment 21

[Bill Gianopoulos [:WG9s]]

That is (In reply to comment #20)
> will this make it into beta3?

Priority P1 plus blocking 1.9.1 combo means if nothing unforseen happens it will be inthe next 1.9.1 milestone.

Comment 22

[Andreas Gal :gal]

#20: yes

Comment 23

[Bill Gianopoulos [:WG9s]]

(In reply to comment #22)
> #20: yes

Well, beta3 seems to be done, and I see no evidence this was checked in to the branch, so exactly what are you basing that yes on?

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It has been checked into 1.9.1 but not trunk:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/df865af82400

For trunk I believe it waits for the next tracemonkey merge.

Comment 25

[Robert Sayre]

sorry I missed the note here

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed on 1.9.1 with builds on Windows and OS X:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090304 Firefox/3.1b3 ID:20090304233338

Comment 27

[Bill Gianopoulos [:WG9s]]

(In reply to comment #24)
> It has been checked into 1.9.1 but not trunk:
> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/df865af82400

Yes, I see it now.  Bug number was not included in the check-in comment.

Comment 29

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/7cd904a49d37

Comment 30

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified on trunk with builds on OS X and Windows:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090310 Minefield/3.2a1pre Ubiquity/0.1.5 ID:20090310030639