| Summary: | REGRESSION: Crash in sanitizeStackForVMImpl when scrolling @ lifehacker.com.au | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Saboff <msaboff> | ||||
| Component: | JavaScriptCore | Assignee: | Michael Saboff <msaboff> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | benjamin, cmarcelo, commit-queue, sondracake50 | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | iPhone / iPad | ||||||
| OS: | All | ||||||
| Attachments: |
|
||||||
|
Description
Michael Saboff
2014-01-31 14:26:40 PST
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> |