Closed Bug 481060 Opened 11 years ago Closed 11 years ago

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

Categories

(Core :: JavaScript Engine, defect, P1, critical)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: whimboo, Assigned: graydon)

References

()

Details

(4 keywords, Whiteboard: fixed-in-tracemonkey)

Crash Data

Attachments

(3 files)

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.
Attached file Stack with gdb
#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.
Flags: blocking1.9.1?
(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.
(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.
Andreas, could it be a regression from your work on bug 479109?
Oh, the trunk nightly from 09022802 works fine and I don't see the crash.
For now I looks like it's a bit harder to get a simplified testcase. Saving the page locally doesn't crash the browser.
Definitely a regression from the patch on bug 479109. Is it a P1?
Blocks: 479109
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 get a crash with at the same point over at http://map.search.ch/ (no login required). Might be easier to simplify...
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.
Summary: Opening the "Create new Project" page on quality.mozilla.org crashes the browser [@ JS_GetMethodById ] → Crash while loading a website [@ JS_GetMethodById][@ js_Blacklist]
(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
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
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
For debug builds you will get an assertion which triggers this crash.
Keywords: assertion
Summary: Crash while loading a website [@ JS_GetMethodById][@ js_Blacklist] → Assertion: "tree->root == tree" and crash while loading a website [@ JS_GetMethodById][@ js_Blacklist]
Assignee: general → graydon
Attached patch Fix the bugSplinter Review
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.
Attachment #365513 - Flags: review?(gal)
(er, also works on the provided testcase, naturally; thanks for that!)
Attachment #365513 - Flags: review?(gal) → review+
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;
>     }
>
http://hg.mozilla.org/tracemonkey/rev/7cd904a49d37
Whiteboard: fixed-in-tracemonkey
will this make it into beta3?
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.
#20: yes
Target Milestone: --- → mozilla1.9.1b3
(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?
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.
Status: NEW → ASSIGNED
Keywords: fixed1.9.1
Target Milestone: mozilla1.9.1b3 → mozilla1.9.2a1
sorry I missed the note here
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
(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.
Duplicate of this bug: 481991
http://hg.mozilla.org/mozilla-central/rev/7cd904a49d37
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Duplicate of this bug: 481436
Crash Signature: [@ JS_GetMethodById] [@ js_Blacklist]
You need to log in before you can comment on or make changes to this bug.