[Bug 54246] New: Full Metal Daemon Muramasa stuck at black screen at boot
https://bugs.winehq.org/show_bug.cgi?id=54246 Bug ID: 54246 Summary: Full Metal Daemon Muramasa stuck at black screen at boot Product: Wine Version: 8.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: thieujank(a)gmail.com Distribution: --- Created attachment 73799 --> https://bugs.winehq.org/attachment.cgi?id=73799 black screen https://www.gog.com/game/full_metal_daemon_muramasa The game stuck at black screen after launch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54246 jank9525 <thieujank(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|8.0-rc2 |8.0 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54246 amberjulee(a)yogirt.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amberjulee(a)yogirt.com --- Comment #1 from amberjulee(a)yogirt.com --- Hey, I'm getting this one too on 9.5! It's definitely a buffer deadlock somewhere in audio system (xaudio? faudio? idk). I'm gonna attach some logs and a small patch to wine-9.5 (commit 7c5b9304a62b794ba07110e15eef6aec3a46ef0a) that generates them. The command I used is FAUDIO_LOG_EVERYTHING=1 WINEDEBUG='+xaudio2,+FAudio,+FACT' ~/wine-dirs/wine32-build/wine muramasa_en.exe I assume XA2SRC_SubmitSourceBuffer in thread 1a4 is game code calling some XAudio code and thread 168 is some sort of background XAudio (FAudio?) worker doing some buffer flushing work and also calling some callbacks from game code (10031CA0 and such seem to be mapped into Mware.dll if my winedbg skills are good enough). I can't figure out what happens in thread 168 though, looks like a game callback is trying to lock an internal xaudio mutex? is that true or am i tripping? Imma keep debugging it but if someone with actual experience knows what happens here it would be pretty cool -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54246 --- Comment #2 from amberjulee(a)yogirt.com --- Created attachment 76248 --> https://bugs.winehq.org/attachment.cgi?id=76248 log generated with a logging patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54246 --- Comment #3 from amberjulee(a)yogirt.com --- Created attachment 76249 --> https://bugs.winehq.org/attachment.cgi?id=76249 logging patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54246 --- Comment #4 from amberjulee(a)yogirt.com --- Created attachment 76253 --> https://bugs.winehq.org/attachment.cgi?id=76253 Mware.dll OnBufferEnd callback disassembly -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54246 --- Comment #5 from amberjulee(a)yogirt.com --- Ok I got it, the 089E8108 critical section is managed by application code. As I understand it: internal FAudio thread A calls FAudio's DecodeBuffers, which calls user callbacks (OnBufferBegin/End) while holding bufferLock. User callbacks try to lock user mutex M. At the same time user thread B calls SubmitSourceBuffer while holding the same user mutex M. SubmitSourceBuffer needs to access bufferLock to add a new buffer into the queue and tries to lock it, but it's already acquired by thread A. Deadlock. Basically what we need is for DecodeBuffers to not hold bufferLock (or any other mutexes I guess?) while calling app callbacks because there's a possibility that the app has some nasty global mutex. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54246 --- Comment #6 from amberjulee(a)yogirt.com --- https://github.com/FNA-XNA/FAudio/pull/337 PR in progress btw (though i've finished the first two chapters and oh brother i absolutely regret debugging this stupid game) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54246 --- Comment #7 from amberjulee(a)yogirt.com --- Fixed in 9.12 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54246 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #8 from Austin English <austinenglish(a)gmail.com> --- (In reply to amberjulee from comment #7)
Fixed in 9.12
Reported fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54246 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 9.13. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla