Comment #1 on issue 21653 by dominic.cooney: Worker layout test
(use-machine-stack.html) crashes/hangs on the mac
http://code.google.com/p/chromium/issues/detail?id=21653
I've done some debugging; here is what I've found.
The worker running use-machine-stack.js crashes with a kernel
protection failure after about ~16.5K invocations of "f" (below)
allocating the 'arguments' object; the transition from JITted JS->C++
is Runtime_NewArgumentsFast (v8/src/runtime.cc) and the KPF is a stack
overflow in innocuous code that's checking whether the global context
map's map word is a context map--all values look innocuous.
The problem is this: v8 is generally hardened against stack overflows
(JITted JS calls Runtime_StackGuard; C++ uses StackLimit or
StackGuard) but Runtime_NewArgumentsFast *isn't*.
The problem is exacerbated by the fact that activations of f are small
(32 bytes) compared to Runtime_NewArgumentsFast and its callees (500+
bytes deep when the overflow occurs) so naturally overflows occur in
Runtime_NewArgumentsFast where there are no overflow checks.
Further, in the worker, the thread's stack is a 512K region (the
default on OS X [1]); it so happens that the default stack limit in
v8's checks is sizeof(pointer) * 128K = 512K on ia32
(execution.cc/kLimitSize). The worker callstack is already 800+ bytes
deep when v8 establishes its StackGuard, so the guard wouldn't trigger
even if Runtime_NewArgumentsFast checked the stack limit.
So why doesn't this crash when run in a page instead of a worker? The
thread stack in a page is a 516K region; there's 4K of headroom for
preamble and Runtime_NewArgumentsFast to "overflow" the v8 512K limit
and for the stack overflow checks in JITted JS to catch the runaway
recursion before KPFing. (BTW, I haven't confirmed if or why this test
works on Windows, but IIRC the default thread stack size on Win32 is
1MB [2].)
I haven't confirmed that Chrome's helper threads' 516K stack sizes are
anything but a coincidence. Still, I think the ideal fix for this is
to start the worker thread with a 516K region. While Chrome's
PlatformThread/Thread have an option to set the stack size, WTF's
createThread doesn't. So I think we should plumb thread creation
through one of these proxy objects in bindings/v8/... and call the
Chrome API to create the worker thread.
Other possibilities:
- Lower the v8 kLimitSize to <<512K to be friendlier to OS X.
- Use the v8 API to set the stack limit. This is an up-front, one-off
thing.
- Modify the v8 API to be able to fiddle with the stack limit per
thread. The capability exists; but it is v8::internal.
function f()
{
arguments.callee.call();
}
[1] http://developer.apple.com/mac/library/qa/qa2005/qa1419.html
[2] http://msdn.microsoft.com/en-us/library/ms686774(VS.85).aspx
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---
