621101 - Assertion failure: &entry->vword.toFunObj() == &v.toObject(), at jsinterp.cpp:2092

Status: RESOLVED DUPLICATE of bug 618007

(Core :: JavaScript Engine, defect)

Description

[Andrew Drake [:adrake]]

Attachment: Test case

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)

Comment 1

[Andrew Drake [:adrake]]

Bisecting yields:

changeset:   58598:38f985b0522c
user:        Luke Wagner <[e-mail]>
date:        Thu Nov 18 10:49:45 2010 -0800
summary:     Bug 561954 - Abort recording earlier to avoid expensive later bails (r=jorendorff)

Comment 2

[Andrew Drake [:adrake]]

Nominating for blocker as this is a regression.

Comment 3

[Paul Biggar]

I'll take this one.

Comment 4

[Paul Biggar]

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

Comment 5

[Jan de Mooij [:jandem]]

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();
        }
    }
}
---

Comment 6

[Paul Biggar]

(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.

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 8

[Paul Biggar]

(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.

Comment 9

[Andrew Drake [:adrake]]

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 .

Comment 10

[Paul Biggar]

OK, I can reproduce jandem's test case (not adrake's).

Today I learned that |-mj| is not the same as |-m -j|.

Comment 11

[Paul Biggar]

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.

Comment 12

[David Mandelin [:dmandelin]]

(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.

Comment 13

[Paul Biggar]

(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.

Comment 14

[David Mandelin [:dmandelin]]

(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"?

Comment 15

[Andrew Drake [:adrake]]

(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.

Comment 16

[Paul Biggar]

(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.

Comment 17

[David Mandelin [:dmandelin]]

(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.