Subj : Re: Crash: JSOP_IFEQX
To   : Oscar
From : Brendan Eich
Date : Tue Sep 07 2004 01:05 pm

Oscar wrote:

> One version of the set of script is: 
> 
> if (1 == 0) {
>   a = a;
> }
> else {
>   a=b.c.d;
>   switch(e) {
>   case 's':
> 
> //  case 't':
>    break;
>   }
> }
> 
> Compilation does not complain (not that it should...) but during the
> interpret phase of execution SM crash, asserts or behaves really strange.


You need to give a complete, ideally minimal test case.  I can't 
evaluate the above, since a, b, b.c, and e are not defined.

I can't make anything odd happen by giving those variables obvious 
values, to wit:

a = 42;
b = {c: {d: 43}};
e = 's';

if (1 == 0) {
   a = a;
}
else {
   a=b.c.d;
   switch(e) {
   case 's':

//  case 't':
    break;
   }
}

Notice by wrapping this source in a script, you can disassemble and 
decompile the generated bytecode:

s = Script( "a = 42;\n" +
             "b = {c: {d: 43}};\n" +
             "e = 's';\n" +
             "\n" +
             "if (1 == 0) {\n" +
             "  a = a;\n" +
             "}\n" +
             "else {\n" +
             "  a=b.c.d;\n" +
             "  switch(e) {\n" +
             "  case 's':\n" +
             "\n" +
             "//  case 't':\n" +
             "   break;\n" +
             "  }\n" +
             "}\n" );
dis(s);
print(s);

This prints the following:

main:
00000:  bindname "a"
00003:  uint16 42
00006:  setname "a"
00009:  popv
00010:  bindname "b"
00013:  name "Object"
00016:  pushobj
00017:  newinit
00018:  name "Object"
00021:  pushobj
00022:  newinit
00023:  uint16 43
00026:  initprop "d"
00029:  endinit
00030:  initprop "c"
00033:  endinit
00034:  setname "b"
00037:  popv
00038:  bindname "e"
00041:  string "s"
00044:  setname "e"
00047:  popv
00048:  one
00049:  zero
00050:  eq
00051:  ifeq 67 (16)
00054:  bindname "a"
00057:  name "a"
00060:  setname "a"
00063:  popv
00064:  goto 98 (34)
00067:  bindname "a"
00070:  name "b"
00073:  getprop "c"
00076:  getprop "d"
00079:  setname "a"
00082:  popv
00083:  name "e"
00086:  lookupswitch offset 12 npairs 1
         "s": 9
00095:  goto 98 (3)

Source notes:
   0:    10 [  10] xdelta
   1:    10 [   0] newline
   2:    38 [  28] xdelta
   3:    38 [   0] newline
   4:    48 [  10] xdelta
   5:    48 [   0] setline  lineno 5
   7:    51 [   3] if-else  offset 13
   9:    54 [   3] newline
  10:    67 [  13] xdelta
  11:    67 [   0] setline  lineno 8
  13:    67 [   0] newline
  14:    73 [   6] pcbase   offset 3
  16:    76 [   3] pcbase   offset 6
  18:    83 [   7] newline
  19:    86 [   3] switch   length 12
  22:    95 [   9] xdelta
  23:    95 [   0] setline  lineno 14
a = 42;
b = {c:{d:43}};
e = "s";
if (1 == 0) {
     a = a;
} else {
     a = b.c.d;
     switch (e) {
       case "s":
         break;
       default:;
     }
}


> The the OP Codes that are executed when interpreting the script above are:
> 
> JSOP_ONE
> JSOP_ZERO
> JSOP_EQ
> JSOP_IFEQX (cond == JS_FALSE) and len = 11
> JSOP_SETNAME  **********************  -> sm asserts


I don't see any such results, with a testcase extrapolated from what you 
post here.  I'm using trunk CVS SpiderMonkey, but I doubt any 1.5 RC had 
any such bug -- we'd have heard about it.

Something's obviously wrong.  Have you modified any sources?  If so, you 
must clobber before recompiling -- the lame Makefile.ref doesn't have 
any header file dependency auto-generation/extraction feature.

In no case should an extended jump bytecode be selected for such a short 
script.

You'll have to debug a bit more, or at least give me a complete testcase 
that I can use to reproduce the problem, if it is really a problem in 
SpiderMonkey, and not something peculiar to your build or source.

/be

.