Bug 128017 - REGRESSION: Crash in sanitizeStackForVMImpl when scrolling @ lifehacker.com.au
Summary: REGRESSION: Crash in sanitizeStackForVMImpl when scrolling @ lifehacker.com.au
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: iPhone / iPad All
: P2 Normal
Assignee: Michael Saboff
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2014-01-31 14:26 PST by Michael Saboff
Modified: 2014-01-31 15:49 PST (History)
3 users (show)

See Also:


Attachments
Patch (10.21 KB, patch)
2014-01-31 14:54 PST, Michael Saboff
fpizlo: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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>