| Summary: | Web Inspector: CRASH when debugger closes while paused and remote inspecting a JSContext | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Joseph Pecoraro <joepeck> | ||||
| Component: | Web Inspector | Assignee: | Joseph Pecoraro <joepeck> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ggaren, joepeck, mark.lam, timothy, webkit-bug-importer | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Attachments: |
|
||||||
(In reply to comment #0) > It seems like we need to handle some special kind of connection closing when we are inside a nested runloop. This is very ugly unless we can just say "continue now, and cleanup on the next runloop". Or we could decide to lazily keep the JSGlobalObjectInspectorController object and some agents around. That could be somewhat useful. E.g. what if you wanted to store console messages, or $1..$9 inspector objects variables. That would mean storing those objects on the JSGlobalObject instead of JSGlobalObjectRemoteDebuggable. Created attachment 224109 [details]
[PATCH] Proposed Fix
This addresses 2 known crashes:
1. Crash when RWI paused and closing RWI
2. Crash when RWI connected and JSGlobalObject is destroyed
This does mean that each JSGlobalObject allocated an InspectorController / Inspector{,Runtime,Debugger,Console} agent. But they do nothing unless you open an RWI connection to the inspector. Soon I will take advantage of the agents being available outside of a remote debug session and stash exception info.
|
* SUMMARY JSContext hosting application crashes when a remote debugger disconnects when it was paused during inspection. * STEPS TO REPRODUCE 1. Launch JSContext test application 2. Inspect JSContext from remote debugger 3. Trigger a breakpoint in the remote debugger 4. Close the remote debugger => CRASH * NOTES It looks like this is because of our nested runloop. 1. Inspector is connected JSGlobalObjectInspectorController and JSGlobalObjectScriptDebugServer are created. 2. Breakpoint is triggered, JSGlobalObjectInspectorController and JSGlobalObjectScriptDebugServer are below the nested runloop on the call stack. 3. Debugger disconnected, while in the nested runloop we receive the disconnect method and decide to teardown the connection => destroy debugger agent, script debug server, and inspector controller 4. Nested call stack resumes inside of a now destructed object => CRASH WebCore gets around this debugging a WebCore::Page by always keeping InspectorController/PageDebuggerAgent/PageScriptDebugServer alive. It just connects/disconnects them. It seems like we need to handle some special kind of connection closing when we are inside a nested runloop. This is very ugly unless we can just say "continue now, and cleanup on the next runloop".