We aren't changing VM::m_lastStackTop when we change threads and therefore stacks.
<rdar://problem/15939497>
Created attachment 222858 [details] Patch
Comment on attachment 222858 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=222858&action=review > Source/JavaScriptCore/runtime/JSLock.cpp:131 > + if (!m_vm->stackPointerAtVMEntry) { > + entryStackPointer = &holder; // A proxy for the current stack pointer. > + m_vm->stackPointerAtVMEntry = entryStackPointer; > + threadData.setSavedReservedZoneSize(m_vm->updateStackLimitWithReservedZoneSize(Options::reservedZoneSize())); > + } If I start executing on Thread A, and then continue executing on Thread B, who sets Thread B's stack limit as the VM's current stack limit? Won't this code allow Thread B to overflow the stack, since Thread B never installs its own stack limit in the VM?
(In reply to comment #3) > (From update of attachment 222858 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=222858&action=review > > > Source/JavaScriptCore/runtime/JSLock.cpp:131 > > + if (!m_vm->stackPointerAtVMEntry) { > > + entryStackPointer = &holder; // A proxy for the current stack pointer. > > + m_vm->stackPointerAtVMEntry = entryStackPointer; > > + threadData.setSavedReservedZoneSize(m_vm->updateStackLimitWithReservedZoneSize(Options::reservedZoneSize())); > > + } > > If I start executing on Thread A, and then continue executing on Thread B, who sets Thread B's stack limit as the VM's current stack limit? > > Won't this code allow Thread B to overflow the stack, since Thread B never installs its own stack limit in the VM? When Thread A drops all locks, we set VM::stackPointerAtVMEntry to nullptr, thus allowing Thread B to install their stack limits. When A reacquires the lock, it will restore its saved stack limit values.
Committed r163214: <http://trac.webkit.org/changeset/163214>