Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 89a06fec3aed7311462e7614afa571d3babf4aef
https://github.com/WebKit/WebKit/commit/89a06fec3aed7311462e7614afa571d3babf4aef
Author: Erica Li <[email protected]>
Date: 2024-02-02 (Fri, 02 Feb 2024)
Changed paths:
A
LayoutTests/compositing/plugins/pdf/pdf-plugin-hang-during-destruction-expected.txt
A
LayoutTests/compositing/plugins/pdf/pdf-plugin-hang-during-destruction.html
M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm
Log Message:
-----------
Deadlock under ~PluginView() with PDFPlugin.
rdar://108489643
https://bugs.webkit.org/show_bug.cgi?id=268536
Reviewed by Simon Fraser.
dataProviderGetBytesAtPosition might be invoked recursively from CG, and it
highly increased the possiblity when the main runloop is destructing the
PDFPlugin,
while the another main runloop is dispatched from
dataProviderGetBytesAtPosition and does not get chance to signal semaphore as
it is waiting current runloop to finish,
that causes deadlock. This change is to stop dispatch main runloop when
document finshed loading and signal the semaphore before main thread calling
waitForCompletion for m_pdfThread.
*
LayoutTests/compositing/plugins/pdf/pdf-plugin-hang-during-destruction-expected.txt:
Added.
* LayoutTests/compositing/plugins/pdf/pdf-plugin-hang-during-destruction.html:
Added.
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm:
(WebKit::PDFIncrementalLoader::clear):
(WebKit::PDFIncrementalLoader::dataProviderGetBytesAtPosition):
Canonical link: https://commits.webkit.org/273988@main
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
