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.
Created attachment 9808 [details] Backtrace from Drosera while deadlocked
Created attachment 9809 [details] Backtrace from Safari while deadlocked
Created attachment 9810 [details] Reduced test case Reduction of the page within the web archive that produces the deadlock. No plugins required.
I have an idea how to fix this.
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
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:
Comment on attachment 9824 [details] Proposed fix r=me
Landed in r15761.
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.