Bug 44690 – Race condition in WorkQueue destruction (could lead to crashes)

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit2

[Adam Roben (:aroben)]

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.

[Adam Roben (:aroben)]

<rdar://problem/8358511>

[Adam Roben (:aroben)]

Once bug 43150 is fixed, this will affect Windows, too.

[Adam Roben (:aroben)]

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.

[Anders Carlsson]

Yeah that sounds good to me.

[Adam Roben (:aroben)]

This same bug exists on Windows.

[Adam Roben (:aroben)]

...as I said it would in comment 2. :-)

[Adam Roben (:aroben)]

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?

[Adam Roben (:aroben)]

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.

[Anders Carlsson]

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.