https://bugs.winehq.org/show_bug.cgi?id=51140
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- Thanks. In the future note that you can compress and attach the text file here.
Anyway, the deadlock is complex and involves three different threads. The video window itself is created on the filter graph's thread, 019c. It has a parent which was created on thread 0024.
011c calls put_Visible(0) on the video window. That ends up doing an inter-thread WM_WINE_SHOWWINDOW to 019c.
As a random side effect of this, the parent gets WM_PAINT, and dutifully calls IVideoWindow::NotifyOwnerMessage() on the video window. This blocks waiting for the graph CS, of course, since we're holding it around put_Visible().
Now, that's not a deadlock by itself, of course, since 019c isn't waiting on anything. What causes the deadlock is that 019c tries to send WM_ERASEBKGND to the parent as a result of being hidden [the "erase parent when hiding or resizing child" code path in USER_SetWindowPos().] Because 0024 is busy waiting for a CS and not processing messages, this causes a deadlock.
There are two potential solutions, both of which may be correct:
(1) We may need to be less restrictive about threading. I haven't tested yet, but it seems plausible to me that the native filter graph doesn't hold the same lock (or perhaps doesn't even hold any lock at all) around put_Visible() and NotifyOwnerMessage().
(2) Every testbot machine, which means XP and later, doesn't seem to send WM_ERASEBKGND there (and, as we would expect, does not in fact send any message to the parent at all.) Presumably *some* version of Windows must have, given ce7bfd6a3f92 (and bug 6006), but I honestly wonder if that entire code path should just be removed. I was actually able to find a copy of the software, and it still works on my windows 7 VM, so maybe the original bug diagnosis was just wrong.