596730 - TM: bug that breaks LLVM-to-JS conversion

Status: RESOLVED DUPLICATE of bug 586866

Description

[Nicholas Nethercote [:njn]]

Attachment 472229 [details] on bug 593659 is an LLVM-to-JS converter.  After unzipping/untarring it, you run it like this:

    PATH-TO-JS-ENGINE/js parser.js < src.cpp.o.llvm

If you run with 'js' or 'js -m' it runs to completion.  With 'js -j' it throws an exception which is caught internally.  So clearly the tracer code is giving different behaviour, presumably erroneously.  The output looks like this:

// Solving Intertyper...
// Cycle start, 1 items.
// Processing using LineSplitter: 1 items out of 1
// Processing using Tokenizer: 12456 items out of 12456
// Working on Intertyper, so far 3.444 seconds. Have 12456 items.
// Processing using Comment: 1 items out of 12456
// Processing using Target: 2 items out of 12455
// Processing using Global: 289 items out of 12453
Exception in process(), current item is: ...
Exception, current selected are: ...
js(56208) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
js(56208) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
utility.js:13: out of memory


except that the "..." strings are huge dumps of stuff.

Comment 1

[David Mandelin [:dmandelin]]

Was this always broken or is it a regression?

Comment 2

[Nicholas Nethercote [:njn]]

It's a regression.

I've reduced this to the following test case:

  function f(a) {
    print("pre-splice: " + a);
    while (a[0] in { 'x': 1 }) {
      a.splice(0, 1);
    }
    print("post-splice: " + a);
  };

  f(["x", "x", "y"]);
  f(["x", "x", "y"]);
  f(["x", "x", "y"]);
  f(["x", "x", "y"]);
  f(["x", "x", "y"]);

Running with -m I get the expected output:

  [ocean:~/moz/ws1/js/src/tmp] js1d32 -m parser.js
  pre-splice: x,x,y
  post-splice: y
  pre-splice: x,x,y
  post-splice: y
  pre-splice: x,x,y
  post-splice: y
  pre-splice: x,x,y
  post-splice: y
  pre-splice: x,x,y
  post-splice: y

Running with -j the while loop finishes too early, as the last line printed shows:

  [ocean:~/moz/ws1/js/src/tmp] js1d32 -j parser.js
  pre-splice: x,x,y
  post-splice: y
  pre-splice: x,x,y
  post-splice: y
  pre-splice: x,x,y
  post-splice: y
  pre-splice: x,x,y
  post-splice: y
  pre-splice: x,x,y
  post-splice: x,y

If you change just about anything in the program, the bug goes away.  This
includes removing the first print() call!

hg bisect blames the following changeset:

  The first bad revision is:
  changeset:   55739:0aa283c6294f
  user:        David Anderson <[e-mail]>
  date:        Fri Oct 22 16:27:28 2010 -0700
  summary:     Trace returning from JSOP_STOP with callDepth=0 (bug 606083, r=billm).

Comment 3

[Alon Zakai (:azakai)]

> hg bisect blames the following changeset: [..] date:        Fri Oct 22 16:27:28 2010 -0700

Hmm the bug was filed a month before that changeset. Maybe a problem with hg blame? Or perhaps this was fixed at some point after the bug was filed, then re-broken?

Comment 4

[Nicholas Nethercote [:njn]]

It's possible the bug in the reduced test case is different to the one in the original test case.  I did confirm manually that r55738 handled the reduced test correctly and r55739 handled it incorrectly.

Comment 5

[Nicholas Nethercote [:njn]]

I just tried the original test case;  backing out bug 606083 doesn't fix it.  Sigh.  Perhaps there are multiple bugs here.  Once the bug affecting the program in comment 2 is fixed I can try reducing the original again.

Comment 6

[Nicholas Nethercote [:njn]]

I opened bug 611575 for the program in comment 2, so we can keep this bug for azakai's original big test program.

Comment 7

[Nicholas Nethercote [:njn]]

Turns out this has the same root cause as bug 593659 after all.

Comment 8

[Nicholas Nethercote [:njn]]

(In reply to comment #7)
> Turns out this has the same root cause as bug 593659 after all.
> 
> *** This bug has been marked as a duplicate of bug 593659 ***

Argh, I modified the wrong bug.

This is actually a dup of bug 586866.