https://bugs.winehq.org/show_bug.cgi?id=51140
Bug ID: 51140 Summary: Silver Chaos game hangs once plays the intro video Product: Wine-staging Version: 6.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: nosferatu.arucard.1983@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Created attachment 70007 --> https://bugs.winehq.org/attachment.cgi?id=70007 The hang issue log
The BL Game Silver Chaos is one of visual novels games that runs fairly nice with Wine, and by the first time using Wine 6.8 version, the in-game intro video playback was finally working. (It happens a few moments when the user start a new game.) The video playback using the standard Wine libraries appears to be fine, but the real issue happens when the user want to skip the video or when the video playback ends. Instead of resume the game, the game hangs, requiring to kill the game and use an downgraded version of Wine (which not support the intro video playback) to bypass the bug and resume playing. Without this bug, this game would gain the platinum rating, since the intro video playback was the missing (minor) issue.
https://bugs.winehq.org/show_bug.cgi?id=51140
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|leslie_alistair@hotmail.com | Component|-unknown |quartz Product|Wine-staging |Wine
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- Probably not a wine-staging bug.
Can you please attach a log with WINEDEBUG=+timestamp,+seh,+quartz,+strmbase,+gstreamer,+qcap,+qedit,+amstream GST_DEBUG=wine:6?
https://bugs.winehq.org/show_bug.cgi?id=51140
--- Comment #2 from Vasco Manteigas nosferatu.arucard.1983@gmail.com --- Created attachment 70009 --> https://bugs.winehq.org/attachment.cgi?id=70009 Requested detailed log
Detailed API log during the video playback. Since the error triggers during the video playback when press any key, it shortens the log file size. (A full played video generates a 14 Mb log file.)
https://bugs.winehq.org/show_bug.cgi?id=51140
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- 12571.020:0168:trace:quartz:VideoWindow_put_Visible (00760728/00760740)->(0) 12571.020:0168:trace:quartz:BaseControlWindowImpl_put_Visible window 00762600, visible 0. 12571.020:0130:trace:quartz:VideoWindow_NotifyOwnerMessage (00760728/00760740)->(00020060, 15, 00000000, 00000000) 12576.017:0130:err:sync:RtlpWaitForCriticalSection section 007607DC "dlls/quartz/filtergraph.c: filter_graph.cs" wait timed out in thread 0130, blocked by 0168, retrying (60 sec)
0168 is getting stuck, probably in user32. Can you please add +msg,+win,+message,+server to the WINEDEBUG channels?
https://bugs.winehq.org/show_bug.cgi?id=51140
--- Comment #4 from Vasco Manteigas nosferatu.arucard.1983@gmail.com --- The log created was stored on my public gist: https://gist.github.com/Arucard1983/a8d9384d1b60e48751c8625a530386c7
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.
https://bugs.winehq.org/show_bug.cgi?id=51140
TOM l12436@yahoo.com.tw changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l12436@yahoo.com.tw
-
WineHQ Bugzilla