Closed Bug 642569 Opened 9 years ago Closed 9 years ago

TI: infinite loop on compiled fannkuch


(Core :: JavaScript Engine, defect)

Other Branch
Not set





(Reporter: azakai, Unassigned)


(Blocks 1 open bug)


(Whiteboard: fixed-in-jaegermonkey)


(3 files)

Attached file compiled fannkuch
The attached script is the fannkuch benchmark compiled to JS. In the jaegermonkey branch, it works if run without the method JIT, for example with argument |3| the output is

  Pfannkuchen(3) = 2.

When enabling the method JIT, the program never completes. Depending on the parameter, it may print a lot of stuff while doing so, for example when run on |3| it prints |1| infinitely.

Example stack when breaking during the infinite loop:

#1  0x0830b15e in js::mjit::EnterMethodJIT (cx=0x8500048, fp=0xb77ac160, code=0xb7780c83, stackLimit=0xb7839070)
    at ./methodjit/MethodJIT.cpp:744
#2  0x0830deeb in CheckStackAndEnterMethodJIT (cx=0x8500048, fp=0xb77ac160, code=0xb7780c83) at ./methodjit/MethodJIT.cpp:773
#3  0x08405f7a in js::Interpret (cx=0x8500048, entryFrame=0xb77ac030, inlineCallCount=3, interpMode=JSINTERP_NORMAL) at jsinterp.cpp:6643
#4  0x081441a9 in js::RunScript (cx=0x8500048, script=0x85a83b0, fp=0xb77ac030) at jsinterp.cpp:659
#5  0x08146a8e in js::Execute (cx=0x8500048, chain=0xb7602028, script=0x85a83b0, prev=0x0, flags=0, result=0x0) at jsinterp.cpp:1062
#6  0x0805eb49 in JS_ExecuteScript (cx=0x8500048, obj=0xb7602028, scriptObj=0xb7602140, rval=0x0) at jsapi.cpp:5233
#7  0x08052a43 in Process (cx=0x8500048, obj=<value optimized out>, filename=0xbffff64a "/dev/shm/tmp/fannkuch.js", forceTTY=0, last=1)
    at js.cpp:453
#8  0x080535ae in ProcessArgs (cx=0x8500048, argc=3, argv=0xbffff4c8, envp=0xbffff4c8) at js.cpp:953
#9  Shell (cx=0x8500048, argc=3, argv=0xbffff4c8, envp=0xbffff4c8) at js.cpp:5755
#10 0x080538b2 in main (argc=4, argv=0xbffff4c4, envp=0xbffff4d8) at js.cpp:5863

(I tried this on jaegermonkey since the compiled script is implicitly statically typed, so was curious how type inference works on it.)
Summary: method JIT infinite loop on compiled fannkuch in jaegermonkey → TI:infinite loop on compiled fannkuch
Summary: TI:infinite loop on compiled fannkuch → TI: infinite loop on compiled fannkuch
Forgot to say, this is on 32-bit Ubuntu 10.10, built SM using --enable-optimize --enable-debug.
Attached file Reduced test case
Reduced to this (weird!) test case.

$ ./js -m -a test.js
Error: Assertion failed: got 0, expected 291
Attached file reduced testcase v2
Good work in reducing the code! It's very hard to find anything to reduce after that. Here is a slightly simplified version though.

Changing almost anything in this code will cause the bug to not appear - the bug depends on the number of unused variables, and on there being an if (and not a while, or no condition at all). An exception is changing the 0,1 constants, which doesn't have an effect.
Whiteboard: fixed
The basic problem is that we used the closed variables information in two different places --- the liveness/used-vars analysis, and the FrameState itself, in subtly inconsistent ways.  The analysis info cuts off at 50 local variables, which is why you need these bizarre test cases (good thing I didn't make it 200!).

This makes the FrameState wholly depend on the analyze::Script for closed/escaping variable information, so there is no inconsistency.  What this loses (and why I didn't do this earlier) is that the FrameState kept track of closed locals from 'let' variables, while the analysis doesn't (and won't), so that 'let' variables can't be held in registers.

Aside: the way we handle accesses to 'let' variables is basically problematic for analysis --- the bytecode analysis, liveness analysis, and type inference.  This could be fixed by making script->nfixed the sum of all 'var' and 'let' variables, i.e. move 'let' vars off the stack and ensure that SETLOCAL N always refers to the same lexical entity.
Whiteboard: fixed → fixed-in-jaegermonkey
Closed: 9 years ago
Resolution: --- → FIXED
The original attachment (not reduced case) doesn't work on latest jaegermonkey with |-m -n|, it segfaults.
Resolution: FIXED → ---
WFM with arguments 3 and 5. I think this fixed it:
Closed: 9 years ago9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.