Closed
Bug 373595
Opened 17 years ago
Closed 17 years ago
"Assertion failure: op == JSOP_ADD" with "1 / 2 .. y"
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jruderman, Unassigned)
Details
(Keywords: crash, testcase)
js> function() { return 1 / 2 .. y; } Assertion failure: op == JSOP_ADD, at jsopcode.c:1784
Reporter | ||
Comment 1•17 years ago
|
||
js> function() { x %= y.@foo; const x; } Assertion failure: op == JSOP_ADD, at jsopcode.c:1784
Reporter | ||
Comment 2•17 years ago
|
||
js> function() { x.@foo < 1; } Assertion failure: op == JSOP_ADD, at jsopcode.c:1784
Comment 3•17 years ago
|
||
Re comment 0: nothing's setting inXML to false after the qnamepart: js> dis(function() { return 1 / x..y; }) flags: LAMBDA INTERPRETED main: 00000: one 00001: name "x" 00004: qnamepart "y" 00007: descendants 00008: div 00009: return 00010: stop Maybe JSOP_DESCENDANTS needs inXML = JS_FALSE? "x..y..z" bytecode indicates this would work, but I'm not 100% sure it works all the time. (Also, see bug 373605 discovered as a variant of this testcase.) Re comment 1 and comment 2: more qnamepart without a corresponding inXML reset cases: js> dis(function() { x %= y.@foo; const x; }) flags: LAMBDA INTERPRETED main: 00000: getvar 0 00003: name "y" 00006: qnamepart "foo" 00009: toattrname 00010: getelem 00011: mod 00012: pop 00013: getvar 0 00016: pop 00017: stop js> dis(function() { x.@foo < 1; }) flags: LAMBDA INTERPRETED main: 00000: name "x" 00003: qnamepart "foo" 00006: toattrname 00007: getelem 00008: one 00009: lt 00010: pop 00011: stop Perhaps JSOP_TOATTRNAME needs to turn off inXML as well? This bug in general is basically the same as bug 373594, except that the ways of triggering failure after not resetting inXML are different -- a question of whether the qname is used in a binary op or not. For example, here's comment 0 modified to fail as in bug 373594: js> function() { var c = x..y; return "a\\"; } function () { var c = x..y; return a\; }
Reporter | ||
Comment 4•17 years ago
|
||
WFM.
Comment 5•17 years ago
|
||
Fixed by patch for bug 372564 I think -- jwalden, can you confirm? /be
Reporter | ||
Comment 6•17 years ago
|
||
WFM on trunk. Marking FIXED per comment 5.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 7•17 years ago
|
||
Although I can reproduce the assertion in the js shell directly I can not reproduce it when the test cases are wrapped in the test framework. I'll leave the tests in my local tree for now but won't check them in as they do not adequately test this bug. in-testsuite- for now.
Flags: in-testsuite-
Reporter | ||
Comment 8•17 years ago
|
||
> I can not reproduce it when the test cases are wrapped in
> the test framework
Try sticking the code that triggers this bug inside "new Function('...')()". I think that helps sometimes.
Comment 9•17 years ago
|
||
(In reply to comment #8) No luck. I'll see what a full browser build from 3/11 does when I have time.
Reporter | ||
Comment 10•17 years ago
|
||
Hmm. Try different ways of decompiling the function -- coerce to string, convert to string, uneval? e.g. "" + (function() { return 1 / 2 .. y; })
Comment 11•17 years ago
|
||
"" + ... worked. Thanks Jesse. /cvsroot/mozilla/js/tests/e4x/QName/regress-373595-01.js,v <-- regress-373595-01.js initial revision: 1.1 /cvsroot/mozilla/js/tests/e4x/QName/regress-373595-02.js,v <-- regress-373595-02.js initial revision: 1.1 /cvsroot/mozilla/js/tests/e4x/QName/regress-373595-03.js,v <-- regress-373595-03.js initial revision: 1.1
Flags: in-testsuite- → in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•