Bug 128017

Summary: REGRESSION: Crash in sanitizeStackForVMImpl when scrolling @ lifehacker.com.au
Product: WebKit Reporter: Michael Saboff <msaboff>
Component: JavaScriptCoreAssignee: Michael Saboff <msaboff>
Status: RESOLVED FIXED    
Severity: Normal CC: benjamin, cmarcelo, commit-queue
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: iPhone / iPad   
OS: All   
Attachments:
Description Flags
Patch fpizlo: review+

Description Michael Saboff 2014-01-31 14:26:40 PST
We aren't changing VM::m_lastStackTop when we change threads and therefore stacks.
Comment 1 Michael Saboff 2014-01-31 14:43:12 PST
<rdar://problem/15939497>
Comment 2 Michael Saboff 2014-01-31 14:54:47 PST
Created attachment 222858 [details]
Patch
Comment 3 Geoffrey Garen 2014-01-31 15:13:54 PST
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?
Comment 4 Michael Saboff 2014-01-31 15:37:10 PST
(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.
Comment 5 Michael Saboff 2014-01-31 15:49:14 PST
Committed r163214: <http://trac.webkit.org/changeset/163214>