Bug 186361

Summary: [Win] Fix WorkQueue crash
Product: WebKit Reporter: Basuke Suzuki <basuke>
Component: Web Template FrameworkAssignee: Basuke Suzuki <basuke>
Status: RESOLVED INVALID    
Severity: Normal CC: basuke, fujii.hironori
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
WIP - first trial none

Basuke Suzuki
Reported 2018-06-06 13:51:05 PDT
WorkQueue::handleCallback was called after WorkQueue::unregisterAndCloseHandle.
Attachments
WIP - first trial (3.84 KB, patch)
2018-06-06 13:52 PDT, Basuke Suzuki 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Basuke Suzuki
Comment 1 2018-06-06 13:52:58 PDT
Created attachment 342080 [details] WIP - first trial
Fujii Hironori
Comment 2 2018-06-06 17:56:10 PDT
It's easy to reproduce this crash by using TestWebKit.
Basuke Suzuki
Comment 3 2018-06-07 08:50:45 PDT
Fujihiro> Question about your patch. This removes the consideration mentioned here: // We're going to make a blocking call to ::UnregisterWaitEx before closing the handle. (The // blocking version of ::UnregisterWaitEx is much simpler than the non-blocking version.) If we // do this on the current thread, we'll deadlock if we're currently in a callback function for // the wait we're unregistering. So instead we do it asynchronously on some other worker thread. I'm not sure this happens in actual use case, but it seems possible. To solve that, how about adding a invalid flag to WorkItemContext? Then we can avoid invocation in a handleCallback after unregisterAndCloseHandle.
Fujii Hironori
Comment 4 2018-06-07 21:01:25 PDT
Year. My patch doesn't do thinkgs right. But, it works for me at least for running WinCairo WK2 stably.
Basuke Suzuki
Comment 5 2018-06-14 11:58:47 PDT
This bug will be handled in https://bugs.webkit.org/show_bug.cgi?id=186582 .
Note You need to log in before you can comment on or make changes to this bug.