Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 7175cd9a22b4a115e8fc413db3fb759b193b0b80
https://github.com/WebKit/WebKit/commit/7175cd9a22b4a115e8fc413db3fb759b193b0b80
Author: Erica Li <ler...@apple.com>
Date: 2024-02-14 (Wed, 14 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
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
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 plugin
has been destroyed 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):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
(WebKit::PDFPluginBase::hasBeenDestroyed const):
Canonical link: https://commits.webkit.org/274694@main
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
