WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
125648
jsCStack: Fix handling of uncaught exceptions
https://bugs.webkit.org/show_bug.cgi?id=125648
Summary
jsCStack: Fix handling of uncaught exceptions
Mark Lam
Reported
2013-12-12 12:49:07 PST
The LLINT handleUncaughtException was not working with the correct CallFrame. It should load the callFrame from VM::callFrameForThrow (which should more appropriately be named callFrameForCatch) instead of assuming that the current frame is the frame that will "catch" i.e. handle the exception. In the case of the uncaught exception case, the "catch" frame should be the global frame which VM::callFrameForThrow provides. The baseline JIT still does not handle uncaught exceptions correctly. Will look at that separately.
Attachments
the patch.
(1.63 KB, patch)
2013-12-12 12:54 PST
,
Mark Lam
no flags
Details
Formatted Diff
Diff
revised patch.
(1.62 KB, patch)
2013-12-12 13:01 PST
,
Mark Lam
ggaren
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Mark Lam
Comment 1
2013-12-12 12:54:09 PST
Created
attachment 219110
[details]
the patch.
Mark Lam
Comment 2
2013-12-12 12:59:41 PST
Comment on
attachment 219110
[details]
the patch. I stand corrected. This patch also fixes uncaught exceptions for the baseline JIT. I previously thought it didn't because I had initially implemented the fix by making llint_slow_handle_exception set the returning ExecState. I've since moved the loading of callFrameForThrow to the LLINT handleUncaughtException thunk which fixes the issue for both the LLINT and the baseline JIT. Will fix ChangeLog and upload another patch.
Mark Lam
Comment 3
2013-12-12 13:01:58 PST
Created
attachment 219111
[details]
revised patch.
Geoffrey Garen
Comment 4
2013-12-12 13:18:34 PST
Comment on
attachment 219111
[details]
revised patch. r=me Do we need this "bpeq CodeBlock[cfr], 1, .calleeFramePopped / loadp CallerFrame[cfr], cfr" business? I don't think so. You should look into removing it. Since we know we're handling an uncaught exception, we know for certain that callFrameForThrow is the sentinel CallFrame, and we don't need to test it.
Mark Lam
Comment 5
2013-12-12 13:19:52 PST
(In reply to
comment #4
)
> (From update of
attachment 219111
[details]
) > r=me > > Do we need this "bpeq CodeBlock[cfr], 1, .calleeFramePopped / loadp CallerFrame[cfr], cfr" business? I don't think so. You should look into removing it. Since we know we're handling an uncaught exception, we know for certain that callFrameForThrow is the sentinel CallFrame, and we don't need to test it.
I'll remove that in my next patch when I fix all exception handling.
Mark Lam
Comment 6
2013-12-12 13:23:26 PST
Thanks for the review. Landed in
r160505
on the jsCStack branch: <
http://trac.webkit.org/r160505
>.
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