1
0
Fork 0
mirror of synced 2025-03-07 03:53:26 +01:00

rtworkq: Avoid closing a thread pool object while its callbacks are running.

Consider a thread A running scheduled_item_cancelable_callback() and a thread B running queue_cancel_item(),
which is the scenario from canceling a work item right after it gets submitted by RtwqScheduleWorkItem().
When the CloseThreadpoolTimer() call in queue_cancel_item() in thread B runs before the queue_release_pending_item()
in scheduled_item_cancelable_callback() in thread A, scheduled_item_cancelable_callback() ends up
calling work_item_Release() and CloseThreadpoolTimer() is called again for the same timer object. So
the thread pool timer object end up getting released while the scheduled_item_cancelable_callback()
is running, triggering the '!object->num_running_callbacks' assertion in tp_object_release(). This
is actually a double free but the assertion happens before the second free could happen. The same
thing could happen for thread pool wait objects as well.

Fix mf and mfmediaengine tests sometimes trigger the '!object->num_running_callbacks' assertion.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55724
This commit is contained in:
Zhiyi Zhang 2024-02-23 16:47:55 +08:00 committed by Alexandre Julliard
parent c5f9d9188a
commit f3bab6c5b7

View file

@ -892,9 +892,13 @@ static HRESULT queue_cancel_item(struct queue *queue, RTWQWORKITEM_KEY key)
IRtwqAsyncResult_SetStatus(item->result, RTWQ_E_OPERATION_CANCELLED);
invoke_async_callback(item->result);
CloseThreadpoolWait(item->u.wait_object);
item->u.wait_object = NULL;
}
else if ((key & SCHEDULED_ITEM_KEY_MASK) == SCHEDULED_ITEM_KEY_MASK)
{
CloseThreadpoolTimer(item->u.timer_object);
item->u.timer_object = NULL;
}
else
WARN("Unknown item key mask %#I64x.\n", key);
queue_release_pending_item(item);