Bug 44690 - Race condition in WorkQueue destruction (could lead to crashes)
Summary: Race condition in WorkQueue destruction (could lead to crashes)
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
Keywords: InRadar
Depends on:
Reported: 2010-08-26 08:48 PDT by Adam Roben (:aroben)
Modified: 2013-01-31 15:50 PST (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Adam Roben (:aroben) 2010-08-26 08:48:11 PDT
Consider the following sequence of events:

1. WorkQueue::scheduleWork is called, scheduling the work to be asynchronously executed on a dispatch queue
2. The WorkQueue is destroyed
3. The dispatch queue calls WorkItem::executeWorkItem

executeWorkItem will dereference the destroyed WorkQueue. This could lead to crashes.
Comment 1 Adam Roben (:aroben) 2010-08-26 08:49:05 PDT
Comment 2 Adam Roben (:aroben) 2010-08-27 12:33:40 PDT
Once bug 43150 is fixed, this will affect Windows, too.
Comment 3 Adam Roben (:aroben) 2010-09-08 12:01:59 PDT
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.
Comment 4 Anders Carlsson 2010-09-08 12:06:25 PDT
Yeah that sounds good to me.
Comment 5 Adam Roben (:aroben) 2011-02-08 09:19:36 PST
This same bug exists on Windows.
Comment 6 Adam Roben (:aroben) 2011-02-08 09:19:54 PST
...as I said it would in comment 2. :-)
Comment 7 Adam Roben (:aroben) 2011-02-08 09:58:49 PST
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?
Comment 8 Adam Roben (:aroben) 2011-02-08 10:24:47 PST
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.
Comment 9 Anders Carlsson 2013-01-31 15:50:24 PST
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.