Summary: | Crash in jsc-layout-tests.yaml/js/script-tests/reentrant-caching.js | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Mark Lam <mark.lam> | ||||
Component: | JavaScriptCore | Assignee: | Michael Saboff <msaboff> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | fpizlo, ggaren, mmirman, msaboff, oliver, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Mark Lam
2014-08-19 11:27:57 PDT
Taking this bug because <https://trac.webkit.org/changeset/163179> is likely responsible for it. The issue is that operationThrowStackOverflowError() unwinds one frame, pointed to by callerFrame. We create a NativeCallFrameTracer object to "wrap" the unwinding. NativeCallFrameTracer sets VM::topCallFrame, which is used as the frame to start unwinding from. If the callee frame, pointed to by exec, is the direct callee of a VM entry frame, then "calleeFrame" will point to a frame somewhat above VM entry frame, BUT we haven't updated VM::topVMEntryFrame accordingly. This messes up unwinding. Patch in progress. Created attachment 236835 [details]
Patch
Comment on attachment 236835 [details]
Patch
Please add a comment to the ChangeLog to explain the difference between when we should use one constructor and the other, so as to explain why only these 3 cases have been fixed to use the new constructor.
r=me with comment added.
Committed r172792: <http://trac.webkit.org/changeset/172792> |