Triggered by the attached test case. It must either be pasted/typed in to the shell or entered via ./js -i < test.js . js> eval("function g(){ debugger; } g()") Assertion failure: &entry->vword.toFunObj() == &v.toObject(), at /home/adrake/src/tm/js/src/jsinterp.cpp:2092 Aborted (core dumped)

Bisecting yields: changeset: 58598:38f985b0522c user: Luke Wagner <lw@mozilla.com> date: Thu Nov 18 10:49:45 2010 -0800 summary: Bug 561954 - Abort recording earlier to avoid expensive later bails (r=jorendorff)

Nominating for blocker as this is a regression.

I'll take this one.

I can't reproduce this on Mac, neither on tip, nor in the cited revision. Going to try in virtualbox on linux.

I still get this assert for the following test case, when I run it with -mj or -mjp. --- for(var k=0; k<10; k++) { function f(x) { } for (var i = 0; i < 10; i++) { var g = eval("(function () { return function(){}})()"); for (var j = 0; j < 5; j++) { g(); } } } ---

(In reply to comment #4) > I can't reproduce this on Mac, neither on tip, nor in the cited revision. Going > to try in virtualbox on linux. Actually, rather than guessing, can you give me the details? Uname and configure line at least. Thanks. (In reply to comment #5) > I still get this assert for the following test case, when I run it with -mj or > -mjp. This one also WORKSFORME. Can I get platform details, configure-line, etc? Thanks.

I was able to reproduce jandem's case in a default debug build (--enable-debug --disable-optimize) on a 64-bit Ubuntu system. I also see it on a 32-bit build for the same machine.

(In reply to comment #7) > I was able to reproduce jandem's case in a default debug build (--enable-debug > --disable-optimize) on a 64-bit Ubuntu system. I also see it on a 32-bit build > for the same machine. I cant reproduce either test using 32-bit Ubuntu 10.10 through virtualbox, using the options billm gave. Can I get a step-by-step to reproduce this? adrake's original comment said it only worked when typed into the shell (tried that), so I guess I'll need pretty detailed instructions.

I've only ever tried this on 64-bit, but here's my configuration with detailed steps: 1. Update/revert to tracemonkey revision 38f985b0522c 2. In js/src, autoconf213 2. In build directory, ~/src/tm/js/src/configure --enable-debug --disable-optimize 3. make 4. wget -O 621101.js https://bug621101.bugzilla.mozilla.org/attachment.cgi?id=499475 5. ./js -i < 621101.js [adrake@charon tm64-js-dbg]$ ./js -i < 621101.js js> setDebuggerHandler("print('hello')") js> setDebug(true) js> debugger; hello js> eval("debugger;") hello js> eval("function g(){ debugger; } g()") Assertion failure: &entry->vword.toFunObj() == &v.toObject(), at /home/adrake/src/tm/js/src/jsinterp.cpp:2091 Aborted (core dumped) With the test case from comment #5 as 621101-2.js: 6. ./js -m -j -p 621101-2.js [adrake@charon tm64-js-dbg]$ ./js -m -j -p 621101-2.js Assertion failure: &entry->vword.toFunObj() == &v.toObject(), at /home/adrake/src/tm/js/src/jsinterp.cpp:2091 Aborted (core dumped) I'm running Fedora 14 x86_64 with all updates applied, GCC 4.5.1 .

OK, I can reproduce jandem's test case (not adrake's). Today I learned that |-mj| is not the same as |-m -j|.

This doesn't occur in non-threadsafe builds, so I think a better use of time is to fix bug 588424 instead. Since firefox is always built with --enable-threadsafe, I guess this shouldn't be a blocker.

(In reply to comment #11) > This doesn't occur in non-threadsafe builds, so I think a better use of time is > to fix bug 588424 instead. > > Since firefox is always built with --enable-threadsafe, I guess this shouldn't > be a blocker. I got a little confused. Are you saying that one way to fix this bug would be to use non-threadsafe mode, and that bug 588424 does that? So that we should make bug 588424 block this one? Are you sure about that? If so, we'd need to make that bug be a blocker, so I'd also like to know what the risk of regressions is for landing bug 588424.

(In reply to comment #12) > I got a little confused. Are you saying that one way to fix this bug would be > to use non-threadsafe mode, and that bug 588424 does that? So that we should > make bug 588424 block this one? Are you sure about that? No, I'm saying that this can't happen in the browser (because I can't reproduce in threadsafe mode), and so this shouldn't be a blocker for Firefox 4. > If so, we'd need to make that bug be a blocker, so I'd also like to know what > the risk of regressions is for landing bug 588424. I don't think we need to make bug 588424 a blocker, unless I need to do that to get it landed.

(In reply to comment #13) > (In reply to comment #12) > > I got a little confused. Are you saying that one way to fix this bug would be > > to use non-threadsafe mode, and that bug 588424 does that? So that we should > > make bug 588424 block this one? Are you sure about that? > > No, I'm saying that this can't happen in the browser (because I can't reproduce > in threadsafe mode), and so this shouldn't be a blocker for Firefox 4. OK, I just need to confirm, then: the original comment said "This doesn't occur in non-threadsafe builds". So there must have been a typo and you meant "This doesn't occur in threadsafe builds"?

(In reply to comment #10) > OK, I can reproduce jandem's test case (not adrake's). Upon further investigation, I just found that the test case is sensitive to whitespace for me (adding three spaces in front of the first line causes the assertion to stop occurring for me). That seems more than scary enough for this to block to me, even if it is tricky to reproduce. I also suspect it could still happen in the browser, but given its fragility it may be tricky to generate a test case.

(In reply to comment #14) > OK, I just need to confirm, then: the original comment said "This doesn't occur > in non-threadsafe builds". So there must have been a typo and you meant "This > doesn't occur in threadsafe builds"? Sorry, there was a typo.

(In reply to comment #16) > (In reply to comment #14) > > > OK, I just need to confirm, then: the original comment said "This doesn't occur > > in non-threadsafe builds". So there must have been a typo and you meant "This > > doesn't occur in threadsafe builds"? > > Sorry, there was a typo. Cool, thanks. I kind of thought that at first. I guess I could have avoided further confusion by just asking on IRC first. Sorry about that.