Closed
Bug 729592
Opened 13 years ago
Closed 4 years ago
[jsdbg2] Debugger internals should probably distinguish handlers requesting throws from failing handlers
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla13
People
(Reporter: jimb, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
The current Debugger implementation can make it hard to distinguish between:
- a handler function that has run successfully, and returned a { throw: V } resumption value, requesting that an exception be thrown; and
- a handler function that has failed and thrown an exception.
For example, Debugger::parseResumptionValue takes a JavaScript resumption value and returns a (JSTrapStatus, Value) pair. If the resumption value is ill-formed, parseResumptionValue calls handleUncaughtException to report the problem, but if that fails, parseResumptionValue will return just as if the original resumption value had requested termination.
This behavior is fine when the intention is to resume the debuggee immediately, but for onPop, we need to call a series of handlers, and successful handlers influence the completion value seen by the next handler, but failing handlers should not. That behavior is hard to implement when parseResumptionValue hides the distinction.
Reporter | ||
Comment 1•13 years ago
|
||
This would be a nice detail to get right, but it doesn't really restrict the utility of onPop much, so it doesn't need to block.
No longer blocks: 674171
Reporter | ||
Comment 2•13 years ago
|
||
It would also be nice to test that things behave as they should when onPop
fails and it's the uncaughtExceptionHook that provides the resumption
value.
Reporter | ||
Comment 3•13 years ago
|
||
I wanted to save some notes I made in figuring out how the pieces should fit together:
-- Here's a Haskell-ish presentation of the types involved with resumption value processing:
data SpiderMonkeyFailure = Exception Value | Termination
data HandlerResult = Success Value | Failure SpiderMonkeyFailure
type ResumptionValue = (JSTrapStatus, Value)
data FallibleDebugger = Success ResumptionValue | Failure SpiderMonkeyFailure
-- Here are the types I think the functions in Debugger.cpp ought to have.
-- They're not what they do now.
-- Fallible because the resumption value could be ill-formed.
parseResumptionValue :: Value -> FallibleDebugger
-- Calling some kind of handler function yields a normal SpiderMonkey result.
call :: ... -> HandlerResult
-- You have to give an onPop handler a resumption value.
callOnPop :: Handler -> ResumptionValue -> HandlerResult
callUncaughtExceptionHook :: SpiderMonkeyFailure -> FallibleDebugger
callUncaughtExceptionHook Termination = Failure Termination :: FallibleDebugger
callUncaughtExceptionHook Exception v
if debugger has no uncaughtExceptionHook defined
then Failure (Exception (noHookSet v)) :: FallibleDebugger
else let hook = the uncaughtExceptionHook
in case call hook v :: HandlerResult of
Failure f -> Failure f :: FallibleDebugger
Success v2 -> parseResumptionValue v2 :: FallibleDebugger
processHandlerResult :: HandlerResult -> FallibleDebugger
processHandlerResult Failure f = callUncaughtExceptionHook f :: FallibleDebugger
processHandlerResult Success v
= case parseResumptionValue v :: FallibleDebugger of
Failure f -> callUncaughtExceptionHook f :: FallibleDebugger
Success sv -> Success sv :: FallibleDebugger
callOnPops :: ResumptionValue -> FallibleDebugger
callOnPops rv
= let af = Nothing
for each onPop handler h ::
case processHandlerResult (callOnPop h rv) :: FallibleDebugger of
Failure f -> af := Just f -- may lose old f!
Success rv2 -> rv := rv2
case af of
Just f -> Failure f :: FallibleDebugger
Nothing -> Success rv :: FallibleDebugger
- All resumeFoo functions leave the AutoCompartment and wrap the Value.
resume :: FallibleDebugger -> ResumptionValue
resume Failure Exception v = (JSTRAP_THROW, confessError v) :: ResumptionValue
resume Failure Termination = (JSTRAP_ERROR, undefined) :: ResumptionValue
resume Success sv = sv :: ResumptionValue
resumeHandlerResult :: HandlerResult -> ResumptionValue
resumeHandlerResult R = resume (processHandlerResult R) :: ResumptionValue
resumeUncatchableError :: SpiderMonkeyFailure -> ResumptionValue
resumeUncatchableError F = resume (Failure F) :: ResumptionValue
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Comment 4•4 years ago
|
||
We now return a boolean following SpiderMonkey's normal error logic and and only use ResumeMode
when processing the final hook result, so I think this is fixed.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•