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)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla13

People

(Reporter: jimb, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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.
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
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.
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
Blocks: 740552
Assignee: general → nobody

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.

Attachment

General

Created:
Updated:
Size: