Bug 128017 – REGRESSION: Crash in sanitizeStackForVMImpl when scrolling @ lifehacker.com.au

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Michael Saboff]

We aren't changing VM::m_lastStackTop when we change threads and therefore stacks.

[Michael Saboff]

<rdar://problem/15939497>

[Michael Saboff]

Created attachment 222858 [details]
Patch

[Geoffrey Garen]

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?

[Michael Saboff]

(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.

[Michael Saboff]

Committed r163214: <http://trac.webkit.org/changeset/163214>