Bug 10200 – [Drosera] Deadlock between Drosera and Safari while loading page

• Component: New Bugs
• Status: CLOSED FIXED

[Mark Rowe (bdash)]

When loading the web archive (attachment 9807 [details]) attached to bug 10057 while Drosera is attached to Safari, Drosera and Safari will reproducibly get into a deadlock situation after continuing the first few JS exceptions that are raised.

[Mark Rowe (bdash)]

Created attachment 9808 [details]
Backtrace from Drosera while deadlocked

[Mark Rowe (bdash)]

Created attachment 9809 [details]
Backtrace from Safari while deadlocked

[Mark Rowe (bdash)]

Created attachment 9810 [details]
Reduced test case

Reduction of the page within the web archive that produces the deadlock.  No plugins required.

[Timothy Hatcher]

I have an idea how to fix this.

[Timothy Hatcher]

I am testing a fix now. This testcase now works with no deadlock. The weird thing is our introspection script is showing up as a script from "about:blank".

(function () { var result = new Array(); for (var x in this) { result.push(x); } return result; })

One interesting note:

Unsafe JavaScript attempt to access frame with URL http://bugzilla.opendarwin.org/attachment.cgi?id=9810&action=view from frame with URL about:blank. Domains must match.
Unsafe JavaScript attempt to access frame with URL http://bugzilla.opendarwin.org/attachment.cgi?id=9810&action=view from frame with URL about:blank. Domains must match.
[3976] http://bugzilla.opendarwin.org/attachment.cgi?id=9810&action=view line 4: ReferenceError: Can't find variable: foo

[Timothy Hatcher]

Created attachment 9824 [details]
Proposed fix

Prevent reentrancy in our debugger callbacks. This was causing a deadlock in Drosera because suspendProcessIfPaused was being called during a DO call into Safari.

Preventing reentrancy also prevents scripts that Drosera injects and evaluates from showing up in rare cases (such as a iframe loading about:blank). I thought this would prevent cases where you call a function from the console and expect it to break on a breakpoint in them, but this appears to never have worked even without this change. When that is figured out we can reconsider a better solution to reentrancy. I have filed that as bug 10214.

I also removed the NSRunLoop runMode:beforeDate: calls since DO handles this for us since we don't use "onway void" as the return type for the callbacks. Note: using onway void for the listener callbacks causes bad synchronization issues and obscure crashes.

* DefaultDelegates/WebScriptDebugServer.m:
(-[WebScriptDebugServer webView:didLoadMainResourceForDataSource:]):
(-[WebScriptDebugServer webView:didParseSource:baseLineNumber:fromURL:sourceId:forWebFrame:]):
(-[WebScriptDebugServer webView:failedToParseSource:baseLineNumber:fromURL:withError:forWebFrame:]):
(-[WebScriptDebugServer webView:didEnterCallFrame:sourceId:line:forWebFrame:]):
(-[WebScriptDebugServer webView:willExecuteStatement:sourceId:line:forWebFrame:]):
(-[WebScriptDebugServer webView:willLeaveCallFrame:sourceId:line:forWebFrame:]):
(-[WebScriptDebugServer webView:exceptionWasRaised:sourceId:line:forWebFrame:]):
* DefaultDelegates/WebScriptDebugServerPrivate.h:

[Darin Adler]

Comment on attachment 9824 [details]
Proposed fix

r=me

[Timothy Hatcher]

Landed in r15761.

[Timothy Hatcher]

Closing since Drosera has been replaced by the new Web Inspector debugger. Moving to the New Bugs component so the Drosera component can be closed and removed.