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)

x86
macOS
defect
Not set
critical

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
js> function() { x %= y.@foo; const x; }        
Assertion failure: op == JSOP_ADD, at jsopcode.c:1784
js> function() { x.@foo < 1; }
Assertion failure: op == JSOP_ADD, at jsopcode.c:1784
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\;
}
WFM.
Fixed by patch for bug 372564 I think -- jwalden, can you confirm?

/be
WFM on trunk.  Marking FIXED per comment 5.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
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-
> 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.
(In reply to comment #8)

No luck. I'll see what a full browser build from 3/11 does when I have time.
Hmm.  Try different ways of decompiling the function -- coerce to string, convert to string, uneval?  e.g.

"" + (function() { return 1 / 2 .. y; })
"" + ... 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+
verified fixed 1.9.0 linux/mac*/windows.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.