[Webkit-unassigned] [Bug 246454] PDFPlugin hangs in deallocation when data load contends with waiting for thread completion

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=246454

--- Comment #4 from Daniel Jalkut <jalkut at red-sweater.com> ---
Unfortunately I don't think the proposed fix will work, because the deadlock prevents the code that might signal the dataSemaphore from ever being reached. So the RunLoop::main().dispatch(...) that gets invoked right before waiting on the semaphore, is prevented from having its block run if/when the main thread is already waiting on the thread to complete in PDFPlugin::destroy.

I tried to adapt the proposed solution to the semaphore wait phase, by replacing dataSemaphore.wait() with 

    while (true) {
        if (monitorPluginRef->isBeingDestroyed()) {
            break;
        }
        if (dataSemaphore.waitFor(100_ms)) {
            break;
        }
    }

This seems to ameliorate the problem, and seems thread safe since the isBeingDestroyed property is only ever going to be true once, and never go back to not being true. But implementing this solution led me to other nuanced issues with exceptions being thrown when the main runloop based code did finally get dispatched, presumably because the plugin is truly gone by that point.

If I put the ->isBeingDestroyed check both inside the main runloop closure and in the semaphore wait construct as above, it seems to escape the code paths without hanging but eventually crashes in an assertion in WebPage::SandboxExtensionTracker::didStartProvisionalLoad. Not really sure how that is connected, but it's a good example of why this is difficult for me to pursue unless we can come up with a "silver bullet" like Darin tried to do here!

I think this line of thinking is the right idea: how to ensure when destroying the plugin that any current OR upcoming attempt to wait on data will be ignored, without leaving dangling closures that might have trouble with that.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20221014/a9f541d5/attachment.htm>