Last Comment Bug 655810 - TI: Infinite loop and memory explosion with array2 test
: TI: Infinite loop and memory explosion with array2 test
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Other Branch
: x86 Linux
: -- normal (vote)
: ---
Assigned To: Jan de Mooij [:jandem]
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: infer-regress
  Show dependency treegraph
Reported: 2011-05-09 13:11 PDT by Alon Zakai (:azakai)
Modified: 2011-05-12 06:33 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

array2 test (22.76 KB, text/plain)
2011-05-09 13:11 PDT, Alon Zakai (:azakai)
no flags Details
Patch (1.02 KB, patch)
2011-05-11 15:03 PDT, Jan de Mooij [:jandem]
bhackett1024: review+
Details | Diff | Splinter Review
Patch (1.21 KB, patch)
2011-05-12 03:04 PDT, Jan de Mooij [:jandem]
bhackett1024: review+
Details | Diff | Splinter Review

Description Alon Zakai (:azakai) 2011-05-09 13:11:47 PDT
Created attachment 531111 [details]
array2 test

The attached script is array2 from emscripten's test suite. With |-m -n| on JM, it enters an apparently infinite loop, and memory usage explodes out of control (be careful when running the script). Works ok with just -m.
Comment 1 Jan de Mooij [:jandem] 2011-05-11 10:10:42 PDT
Can you still reproduce this? Works for me with 32-bit and 64-bit OS X shell, both |-m -n| and |-m -a -n|.
Comment 2 Alon Zakai (:azakai) 2011-05-11 10:28:12 PDT
I still see this on Linux 32. Might be a platform specific thing then.

I get the same on most other emscripten tests as well (this is among the first in the list, so I saw it first).
Comment 3 Jan de Mooij [:jandem] 2011-05-11 12:20:07 PDT
Ah this is interesting, debug build works on Linux 32-bit, but I can reproduce with a release build. Linux 32-bit tinderbox has the same problem, orange caused by time-outs. I'll reduce this now.
Comment 4 Jan de Mooij [:jandem] 2011-05-11 15:03:54 PDT
Created attachment 531766 [details] [diff] [review]

There are different versions of JS_FLOOR_LOG2 macro, apparently the optimized version returned an invalid value if the result is signed. The register was not in freeMask, causing an infinite loop in FrameState::merge (it was busy generating code, causing the memory explosion).
Comment 5 Brian Hackett (:bhackett) 2011-05-11 15:30:25 PDT
Comment on attachment 531766 [details] [diff] [review]

Weird, any other hits on this?  possible to put a comment on the macro?
Comment 6 Jan de Mooij [:jandem] 2011-05-11 16:57:03 PDT
I think the fix is correct, but it looks like JS_FLOOR_LOG2 is a red herring. The problem seems to be somewhere outside peekReg. Probably a bug in GCC 4.5 with -O3, I'll look closer tomorrow.
Comment 7 Jan de Mooij [:jandem] 2011-05-12 03:04:37 PDT
Created attachment 531880 [details] [diff] [review]

The (RegisterID)ireg cast was confusing GCC when ireg is a FP register. So maybe it's not a GCC bug but undefined behavior. We don't even need the int -> unsigned change but I left it in, it seems to be the right type.

There's another (RegisterID) cast in FrameState.cpp, but it's valid because RegisterID ranges from 0 to TotalRegisters.
Comment 8 Jan de Mooij [:jandem] 2011-05-12 06:33:44 PDT

Note You need to log in before you can comment on or make changes to this bug.