[Webkit-unassigned] [Bug 246454] New: 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

            Bug ID: 246454
           Summary: PDFPlugin hangs in deallocation when data load
                    contends with waiting for thread completion
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: PDF
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jalkut at red-sweater.com
                CC: thorton at apple.com

Created attachment 462960

  --> https://bugs.webkit.org/attachment.cgi?id=462960&action=review

example source file to reproduce the hang in Safari

When a PDFPlugin instance is destroyed while it's still waiting for data to load, a deadlock may occur while the data loading thread attempts to dispatch to the main thread, and the main thread waits for the data loading thread to complete.

The specific contention seems to be between the code at

https://github.com/WebKit/WebKit/blob/main/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm#L879

which requires an async dispatch to the main thread, while PDFPlugin destructor on the main thread:

https://github.com/WebKit/WebKit/blob/main/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm#L1877

waits for the thread to terminate.

In real world scenarios this bug was observed in NetNewsWire, when viewing RSS articles that have PDF embedded in them. The ability in NNW to rapidly flip through multiple content loads by arrowing through articles exacerbates the problem.

A concise example of this bug can be produced without referencing any actual PDF data but by loading a simple HTML document like (also attached as test.html):

<textarea>This page will hang if reloaded repeatedly</textarea>
<object type="application/pdf" style="width:100%;height:100%"></object>                                                                                  

And then reloading it. It seems that the particular case of not supplying a data parameter is even better at exacerbating the problem than the real-world example of a PDF that might just take a while to load.

I suspect a good fix would be to build in some mechanism so that PDFPlugin::unconditionalCompleteOutstandingRangeRequests can also signal the PDF document thread to stop waiting on its local dataSemaphore. I tried to prototype such a fix but my C++ skills are not great and the right fix might be a bit more nuanced than I'm imagining.

I wonder if the pattern using m_abortSemaphore in SourceBufferPrivateAVFObjC might be a good model to follow? One complication is that the PDFPlugin seems to have a few separate data loading semaphore code paths so it might not be as simple as covering the case I higlighted here.

-- 
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/20221013/2be573c6/attachment.htm>