WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 148666
148076
jsc-tailcall: Handling exception in caller frame cannot unwind past VMEntry frame
https://bugs.webkit.org/show_bug.cgi?id=148076
Summary
jsc-tailcall: Handling exception in caller frame cannot unwind past VMEntry f...
Michael Saboff
Reported
2015-08-17 06:56:42 PDT
When we have an exception that we process from the caller's frame, we cannot unwind past the VMEntry frame. Currently, if a stack overflow check exception happens for a JavaScript frame immediately below a VMENtry frame, we'll unwind past not only the VMENtry frame, but also any C++ frames to find a JavaScript frame with a catch block. This "works" for current code, but breaks when callee save registers need to be properly restored during the unwind process. It can also leak and C++ objects allocated by the C++ code.
Attachments
Patch
(8.02 KB, patch)
2015-08-17 07:11 PDT
,
Michael Saboff
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Michael Saboff
Comment 1
2015-08-17 07:11:46 PDT
Created
attachment 259145
[details]
Patch
WebKit Commit Bot
Comment 2
2015-08-17 07:12:59 PDT
Attachment 259145
[details]
did not pass style-queue: ERROR: Source/JavaScriptCore/jit/JITExceptions.h:38: The parameter name "unwindStart" adds no information, so it should be removed. [readability/parameter_name] [5] Total errors found: 1 in 8 files If any of these errors are false positives, please file a bug against check-webkit-style.
Basile Clement
Comment 3
2015-08-17 15:47:46 PDT
Comment on
attachment 259145
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=259145&action=review
> Source/JavaScriptCore/ChangeLog:32 > + (JSC::LLInt::llint_stack_check): Changed to process the exception in the currnet frame.
currnet -> current
> Source/JavaScriptCore/jit/JITExceptions.cpp:67 > + callFrame = callFrame->callerFrame(vmEntryFrame);
Nit: You can directly use callFrame->callerFrame() here.
> Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:487 > - CommonSlowPaths::interpreterThrowInCaller(exec, createStackOverflowError(exec)); > - pc = returnToThrowForThrownException(exec); > + vm.throwException(exec, createStackOverflowError(exec)); > + pc = returnToThrow(exec);
I think this should be consistent amongst all the tiers, see below.
> Source/JavaScriptCore/llint/LowLevelInterpreter.asm:923 > - subp maxFrameExtentForSlowPathCall, sp # Set up temporary stack pointer for call > + # Set up temporary stack pointer for call including callee saves > + subp maxFrameExtentForSlowPathCall + CalleeSaveSpaceStackAligned, sp
If I understand correctly, the callee save registers are saved below the stack pointer at this point. Could we instead move the saving of callee save after the stack check/setup (which would allow us to continue throwing in the caller)?
Michael Saboff
Comment 4
2015-08-17 16:04:11 PDT
(In reply to
comment #3
)
> Comment on
attachment 259145
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=259145&action=review
> > > Source/JavaScriptCore/ChangeLog:32 > > + (JSC::LLInt::llint_stack_check): Changed to process the exception in the currnet frame. > > currnet -> current
Fixed locally.
> > Source/JavaScriptCore/jit/JITExceptions.cpp:67 > > + callFrame = callFrame->callerFrame(vmEntryFrame); > > Nit: You can directly use callFrame->callerFrame() here.
Changed locally.
> > Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:487 > > - CommonSlowPaths::interpreterThrowInCaller(exec, createStackOverflowError(exec)); > > - pc = returnToThrowForThrownException(exec); > > + vm.throwException(exec, createStackOverflowError(exec)); > > + pc = returnToThrow(exec); > > I think this should be consistent amongst all the tiers, see below.
The reason for the difference is that the LLInt makes a call to lint_stack_check() and the way these slow path calls work is that they pass the PC as the second argument and return the possibly modified PC as the first of two values. In the LLInt, the PC value is a callee save and therefore it is easiest to preserve the callee saves, set up the PC before making the stack check call. Given that we need to unwind and restore callee saves for the frame where the stack overflow occurred. The JITs don't have this issue.
> > Source/JavaScriptCore/llint/LowLevelInterpreter.asm:923 > > - subp maxFrameExtentForSlowPathCall, sp # Set up temporary stack pointer for call > > + # Set up temporary stack pointer for call including callee saves > > + subp maxFrameExtentForSlowPathCall + CalleeSaveSpaceStackAligned, sp > > If I understand correctly, the callee save registers are saved below the > stack pointer at this point. Could we instead move the saving of callee save > after the stack check/setup (which would allow us to continue throwing in > the caller)?
See above.
Michael Saboff
Comment 5
2015-08-17 16:58:05 PDT
Committed
r188555
: <
http://trac.webkit.org/changeset/188555
>
Basile Clement
Comment 6
2015-08-31 18:08:52 PDT
*** This bug has been marked as a duplicate of
bug 148666
***
Csaba Osztrogonác
Comment 7
2015-09-14 10:59:32 PDT
Comment on
attachment 259145
[details]
Patch Cleared review? from
attachment 259145
[details]
so that this bug does not appear in
http://webkit.org/pending-review
. If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug