Summary: | Crash in thread pool because WorkQueue keeps waiting on closed HANDLEs | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Adam Roben (:aroben) <aroben> | ||||||
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | abarth, andersca, eric, sam, webkit.review.bot | ||||||
Priority: | P2 | Keywords: | InRadar, PlatformOnly | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Bug Depends on: | 43150 | ||||||||
Bug Blocks: | |||||||||
Attachments: |
|
Description
Adam Roben (:aroben)
2010-07-22 08:17:04 PDT
It's possible that this is a cause of bug 42785. See discussion in that bug for more details. (In reply to bug 42785 comment #8) > I think using a pair of events will work. The first event will be used to tell the work queue thread to stop waiting. The second event will be used to tell the main thread that waiting has stopped. Anders informed me that this is not a good strategy. Waiting on the work queue thread is dangerous because the work queue thread might wait on the first thread, resulting in a deadlock. I think adding an unregisterAndCloseHandle function to WorkQueue might be the way to go. We'd add the handle to a m_handlesToClose Vector and signal m_performWorkEvent. Then the work queue thread would close all handles in m_handlesToClose when it wakes up. *** Bug 43148 has been marked as a duplicate of this bug. *** I've been working on switching over to using an I/O completion port in WorkQueue. This would make it unnecessary to unregister a HANDLE; you can just close it and stop worrying. However, I'm seeing spurious reads in the web process. I.e., the web process will request 1 byte of the next message from the pipe, and then will be told that 207 bytes were read. This doesn't make any sense! Windows shouldn't be reading more than we asked it to; where would it store the data? I'm going to base the fix for this on the fix for bug 43150. Created attachment 65752 [details]
Teach WorkQueue how to stop waiting on objects on Windows
Comment on attachment 65752 [details]
Teach WorkQueue how to stop waiting on objects on Windows
This patch introduces a crash due to WorkItemWin being destroyed when it is currently being used in handleCallback.
To fix this we shouldn't destroy the WorkItemWin until we've unregistered the wait.
Created attachment 66933 [details]
Teach WorkQueue how to stop waiting on objects on Windows
Committed r67013: <http://trac.webkit.org/changeset/67013> http://trac.webkit.org/changeset/67013 might have broken Qt Linux Release The following changes are on the blame list: http://trac.webkit.org/changeset/67013 http://trac.webkit.org/changeset/67014 |