Closed Bug 596730 Opened 15 years ago Closed 15 years ago

TM: bug that breaks LLVM-to-JS conversion

Categories

(Core :: JavaScript Engine, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 586866
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: n.nethercote, Unassigned)

References

Details

(Keywords: regression, testcase)

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.
blocking2.0: --- → ?
blocking2.0: ? → betaN+
Was this always broken or is it a regression?
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 <danderson@mozilla.com> date: Fri Oct 22 16:27:28 2010 -0700 summary: Trace returning from JSOP_STOP with callDepth=0 (bug 606083, r=billm).
Blocks: 606083
Keywords: regression, testcase
> 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?
OS: Mac OS X → All
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.
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.
I opened bug 611575 for the program in comment 2, so we can keep this bug for azakai's original big test program.
Depends on: 611575
No longer blocks: 606083
Turns out this has the same root cause as bug 593659 after all.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
(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.
You need to log in before you can comment on or make changes to this bug.