Summary: | Race condition in WorkQueue destruction (could lead to crashes) | ||
---|---|---|---|
Product: | WebKit | Reporter: | Adam Roben (:aroben) <aroben> |
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | andersca, sam |
Priority: | P2 | Keywords: | InRadar |
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All |
Description
Adam Roben (:aroben)
2010-08-26 08:48:11 PDT
Once bug 43150 is fixed, this will affect Windows, too. Maybe we should add a handle object that holds a weak reference to the WorkQueue. The handle is what gets passed to executeWorkItem. When WorkQueue gets invalidated, it can null out the handle's weak reference. Yeah that sounds good to me. This same bug exists on Windows. It isn't clear to me what the expected behavior of WorkQueue::invalidate is. Possible behaviors include: 1) No WorkItems will start executing after WorkQueue::invalidate returns. 2) No WorkItems will be currently executing after WorkQueue::invalidate returns. (1) seems like it must be intended. But what about (2)? Anders? Anders says (1) is intended, but not (2). It is up to callers to deal with a WorkItem being in progress when WorkQueue::invalidate is called. One convenience for most callers is that member-function WorkItems ref the object they're going to call, so those objects don't have to worry about being deleted in the middle of a WorkItem executing. http://trac.webkit.org/changeset/141497 changed the semantics of WorkQueue; it's now a ref-counted class that's implicitly kept alive when executing blocks. |