The current stack limit computation assumes that the stack is allocated in high memory. On Windows, the stack seems to be allocated very near address 0, and is smaller in size than our Options::maxPerThreadStackUsage(). This combination triggers a bug where StackBounds::recursionLimit() underflows and computes a limit address that is ridiculously high in memory. The net effect is that the Windows port thinks its out of stack space all the time. Fix coming.
Created attachment 223195 [details] fixed StackBound::recursionLimit() to handle underflows.
Comment on attachment 223195 [details] fixed StackBound::recursionLimit() to handle underflows. View in context: https://bugs.webkit.org/attachment.cgi?id=223195&action=review > Source/JavaScriptCore/llint/LowLevelInterpreter.cpp:156 > + CLoopRegister() { i = static_cast<intptr_t>(0xbadbeef0baddbeef); } tasty, but won't this break in 32bit builds?
Comment on attachment 223195 [details] fixed StackBound::recursionLimit() to handle underflows. View in context: https://bugs.webkit.org/attachment.cgi?id=223195&action=review >> Source/JavaScriptCore/llint/LowLevelInterpreter.cpp:156 >> + CLoopRegister() { i = static_cast<intptr_t>(0xbadbeef0baddbeef); } > > tasty, but won't this break in 32bit builds? Nope. That's what the static_cast<intptr_t> takes care of for me. I verified that the 32-bit build is happy.
Created attachment 223198 [details] I fixed the patch, but apparently uploaded the wrong one. Round 2.
Comment on attachment 223198 [details] I fixed the patch, but apparently uploaded the wrong one. Round 2. A bad patch again. Redoing.
Created attachment 223200 [details] Trying again.
Patch 3 has passed the layout tests with a debug build.
Comment on attachment 223200 [details] Trying again. r=me
Comment on attachment 223200 [details] Trying again. Clearing flags on attachment: 223200 Committed r163428: <http://trac.webkit.org/changeset/163428>
All reviewed patches have been landed. Closing bug.