Closed Bug 642569 Opened 9 years ago Closed 9 years ago
TI: infinite loop on 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 123 213 231 321 312 132 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.
Reduced to this (weird!) test case. $ ./js -m -a test.js Error: Assertion failed: got 0, expected 291
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.
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. http://hg.mozilla.org/projects/jaegermonkey/rev/d7fa1607c33e
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
The original attachment (not reduced case) doesn't work on latest jaegermonkey with |-m -n|, it segfaults.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
WFM with arguments 3 and 5. I think this fixed it: http://hg.mozilla.org/projects/jaegermonkey/rev/6474999c14c6
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.