From: Zhiyi Zhang zzhang@codeweavers.com
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 --- dlls/rtworkq/queue.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/dlls/rtworkq/queue.c b/dlls/rtworkq/queue.c index 15b8da47639..40471ff5234 100644 --- a/dlls/rtworkq/queue.c +++ b/dlls/rtworkq/queue.c @@ -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);