253952 - Assertion failure at jsemit.c line 3034

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Kenneth Herron]

This is no mandrake linux 9.2 using gcc 3.3.1. I build my own mozilla from
source; this copy was pulled and built the morning of july 31st.

I encountered this by following the sample URL, which is apparently redirects to
<http://www.smh.com.au/articles/2004/08/01/1091298577466.html>. The page which
actually displays is a page served by www.smh.com.au warning the user that
smh.com.au is phasing in user registrations. I also reproduced the problem by
pasting <http://www.smh.com.au/articles/2004/08/01/1091298577466.html> into a
fresh browser window; in this case the article loaded but the assertion failure
still triggered.

Either way, the js engine asserts while parsing
<http://smh.com.au/sitecatalyst/s_code_remote.js>:

(gdb) bt
#0  0x407bb006 in nanosleep () from /lib/i686/libc.so.6
#1  0xffffffa0 in ?? ()
#2  0x407bae37 in sleep () from /lib/i686/libc.so.6
#3  0x08069546 in ah_crap_handler (signum=6)
    at /extra/kherron/moz/mozilla/xpfe/bootstrap/nsSigHandlers.cpp:135
#4  0x4206d460 in nsProfileLock::FatalSignalHandler (signo=6)
    at
/extra/kherron/moz/mozilla/profile/dirserviceprovider/src/nsProfileLock.cpp:208
#5  0x400f14ec in __pthread_clock_settime () from /lib/i686/libpthread.so.0
#6  <signal handler called>
#7  0x40738d71 in kill () from /lib/i686/libc.so.6
#8  0x400ee871 in pthread_kill () from /lib/i686/libpthread.so.0
#9  0x400eeb8b in raise () from /lib/i686/libpthread.so.0
#10 0x40738b04 in raise () from /lib/i686/libc.so.6
#11 0x4073a1e0 in abort () from /lib/i686/libc.so.6
#12 0x40084119 in JS_Assert (s=0x4008c4b7 "0",
    file=0x400897a0 "/extra/kherron/moz/mozilla/js/src/jsemit.c", ln=3034)
    at /extra/kherron/moz/mozilla/js/src/jsutil.c:155
#13 0x4003f22b in js_EmitTree (cx=0x9822af0, cg=0xbfffe9c4, pn=0x9798910)
    at /extra/kherron/moz/mozilla/js/src/jsemit.c:3034
#14 0x4006d48e in Statements (cx=0x9822af0, ts=0x9798598, tc=0xbfffe9c4)
    at /extra/kherron/moz/mozilla/js/src/jsparse.c:1026
#15 0x4006c76c in js_CompileTokenStream (cx=0x9822af0, chain=0x0,
    ts=0x9798598, cg=0xbfffe9c4)
    at /extra/kherron/moz/mozilla/js/src/jsparse.c:451
#16 0x400298f3 in CompileTokenStream (cx=0x9822af0, obj=0x92a7420,
    ts=0x9798598, tempMark=0x0, eofp=0x0)
    at /extra/kherron/moz/mozilla/js/src/jsapi.c:3097
#17 0x40029a9f in JS_CompileUCScriptForPrincipals (cx=0x9822af0,
    obj=0x92a7420, principals=0x8daaa2c, chars=0x9a81b20, length=17286,
    filename=0x9aefe88 "http://smh.com.au/sitecatalyst/s_code_remote.js",
    lineno=1) at /extra/kherron/moz/mozilla/js/src/jsapi.c:3178
#18 0x4002a46e in JS_EvaluateUCScriptForPrincipals (cx=0x9822af0,
    obj=0x92a7420, principals=0x8daaa2c, chars=0x9a81b20, length=17286,
    filename=0x9aefe88 "http://smh.com.au/sitecatalyst/s_code_remote.js",
    lineno=1, rval=0xbfffeb68)
    at /extra/kherron/moz/mozilla/js/src/jsapi.c:3630
#19 0x41df8fa7 in nsJSContext::EvaluateString (this=0x9822aa8,
    aScript=@0x92ae548, aScopeObject=0x92a7420, aPrincipal=0x8daaa28,
---Type <return> to continue, or q <return> to quit---q
aURL=0x9aeQuit
) at /extra/kherron/moz/mozilla/dom/src/base/nsJSEnvironment.cpp:994
#20 0x41cb12ac in nsScriptLoader::EvaluateScript (this=0xbfffec80,
    aRequest=0x92ae530, aScript=@0x92ae548)
    at /extra/kherron/moz/mozilla/content/base/src/nsScriptLoader.cpp:668
#21 0x41cb0f79 in nsScriptLoader::ProcessRequest (this=0x8f82cd0,
    aRequest=0x92ae530)
    at /extra/kherron/moz/mozilla/content/base/src/nsScriptLoader.cpp:586
#22 0x41cb1ceb in nsScriptLoader::OnStreamComplete (this=0x8f82cd0,
    aLoader=0x9794b18, aContext=0x92ae530, aStatus=150482156,
    stringLen=4294967295, string=0x98639ef "")

<snip>

(gdb) frame 13
#13 0x4003f22b in js_EmitTree (cx=0x9822af0, cg=0xbfffe9c4, pn=0x9798910)
    at /extra/kherron/moz/mozilla/js/src/jsemit.c:3034
3034                          default:          JS_ASSERT(0);
Current language:  auto; currently c
(gdb) p pn3
$1 = (JSParseNode *) 0x9b46e90
(gdb) p *pn3
$2 = {pn_type = TOK_NAME, pn_pos = {begin = {index = 9, lineno = 34}, end = {
      index = 10, lineno = 34}}, pn_op = 154, pn_offset = 168,
  pn_arity = PN_NAME, pn_u = {func = {funAtom = 0x8124ea0, body = 0x0,
      flags = 32, tryCount = 5}, list = {head = 0x8124ea0, tail = 0x0,
      count = 32, extra = 5}, ternary = {kid1 = 0x8124ea0, kid2 = 0x0,
      kid3 = 0x20}, binary = {left = 0x8124ea0, right = 0x0, val = 32},
    unary = {kid = 0x8124ea0, num = 0}, name = {atom = 0x8124ea0, expr = 0x0,
      slot = 32, attrs = 5}, dval = 6.6905136571969587e-316}, pn_next = 0x0}

pn_op 154 is JSOP_GETGVAR, which isn't handled by the switch statement starting
at jsemit.c line 3026.

I suspect this is related to the checkin for bug 252892.

Comment 1

[Brendan Eich [:brendan]]

Sorry, I forgot about the GVAR ops, which are only on the trunk.

/be

Comment 2

[Brendan Eich [:brendan]]

Attachment: fix

Comment 3

[Brendan Eich [:brendan]]

Fixed.

/be