http://bugs.winehq.org/show_bug.cgi?id=22978
Summary: SimCity2000: race condition causes crash in MCI during startup Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net
Created an attachment (id=28457) --> (http://bugs.winehq.org/attachment.cgi?id=28457) mci+winmm trace & crash backtrace
The attached log shows a crash that is triggered because the asynchronous mciseq/mcimidi player is still attempting to open the device while the main thread already successfully called MCI_CLOSE. The mcimidi player does not implement proper locking. Unlike mciwave, its state variable is not yet set to MCI_MODE_PLAY when opening the MIDI device, which lets MCI_CLOSE not see something is busy playing. Actually, even looking at mciwave, one can construct unfortunate sequences of scheduling that would cause mciwave to hang in such a situation. So there's no trivial patch simply moving wmm->dwStatus = MCI_MODE_PLAY; a couple of lines up.
The crash generally occurs when starting SimCity 2000 using "wine 'C:\Program...\Game\simcity.exe'" Curiously, "wine start simcity.exe" always works. As I said, it's a race condition. It seems like sometimes, the initialisation of WINMM and MIDI takes a long time. The bug is then triggered when MCI_CLOSE is called by the application.
MCI_CLOSE is called, among others, when clicking "exit" in the initial menu. Often enough, the app crashes before showing this menu. IMHO, the fact that the app calls MCI_CLOSE that early is triggered by another bug in Wine that AppDB testers have mentioned every now and often, but never put to Bugzilla: SimCity 2000 starts fine (showing its logo) when using full screen mode, but needs a resize or uniconify when using a virtual desktop: then presumably, the app sends MCI_CLOSE to stop the music, causing or not a crash via the present race condition. BTW, since the crash occurs in the asynchronous MCI MIDI player, the app nevertheless works...
This issue has nothing to do with the bug, presumably in the app, that "wine simcity.exe" crashes whereas "wine 'c:\full\path\simcity.exe'" (should) work.
http://bugs.winehq.org/show_bug.cgi?id=22978
--- Comment #1 from Jörg Höhle hoehle@users.sourceforge.net 2010-05-31 12:36:44 --- Created an attachment (id=28458) --> (http://bugs.winehq.org/attachment.cgi?id=28458) winmm&mci trace
By comparison, this log shows a case where MCI_CLOSE is called while the state is MCI_MODE_PLAYING (the playloop started), causing a regular stop. This one was created using "wine start simcity.exe".
http://bugs.winehq.org/show_bug.cgi?id=22978
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.2-rc2
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-31 20:49:36 --- In future please specify Wine version.
http://bugs.winehq.org/show_bug.cgi?id=22978
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #3 from Jerome Leclanche adys.wh@gmail.com 2012-03-08 09:30:45 CST --- Joerg, has this been taken care of?
http://bugs.winehq.org/show_bug.cgi?id=22978
--- Comment #4 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-09 03:57:05 CST --- No. In early 2011, I was slowly preparing a rewrite of MCIMIDI when in June, the winmm->mmdevapi rewrite was imposed upon the rest of us :-) That has kept me busy ever since and is not over yet.
http://bugs.winehq.org/show_bug.cgi?id=22978
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kapfell@gmx.de
--- Comment #5 from Jörg Höhle hoehle@users.sourceforge.net 2012-09-11 08:50:02 CDT --- *** Bug 30978 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22978
--- Comment #6 from Jörg Höhle hoehle@users.sourceforge.net 2012-09-20 06:58:30 CDT --- Created attachment 41743 --> http://bugs.winehq.org/attachment.cgi?id=41743 mcimidi diff against 1.5.13 (likely works with any 1.4/1.5.*[*])
My work on mcimidi is not over yet, but the attached code goes a long way towards thread-safety and compatibility. Please check and report.
[*] Because of my commit 5 days ago, the attached diff works atop 1.5.13, but would need cherry-pick commit 5b3121b63265a34d36eabecca1ad0108f1be633a to apply to any Wine version since the previous change on 2012-01-04.
http://bugs.winehq.org/show_bug.cgi?id=22978
--- Comment #7 from kapfell@gmx.de 2012-09-21 13:42:04 CDT --- (In reply to comment #6)
Created attachment 41743 [details] mcimidi diff against 1.5.13 (likely works with any 1.4/1.5.*[*])
My work on mcimidi is not over yet, but the attached code goes a long way towards thread-safety and compatibility. Please check and report.
SharpEye v2.68 no longer crashes wine (version 1.5.13, with mcimidi patch applied) when attempt is made to play music (File->Open Music...). However, no sound is output either.
http://bugs.winehq.org/show_bug.cgi?id=22978
--- Comment #8 from kapfell@gmx.de 2012-09-21 13:44:59 CDT --- Created attachment 41771 --> http://bugs.winehq.org/attachment.cgi?id=41771 Wine (version 1.5.13, with mcimidi patch) log file
Created with WINEDEBUG=+tid,+mmdevapi,+winmm,+driver,+midi,+dsound,+dsound3d,+dmusic,+mci,+oss,+alsa,+coreaudio
http://bugs.winehq.org/show_bug.cgi?id=22978
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #41743|0 |1 is obsolete| |
--- Comment #9 from Jörg Höhle hoehle@users.sourceforge.net 2012-09-21 15:38:56 CDT --- Created attachment 41772 --> http://bugs.winehq.org/attachment.cgi?id=41772 mcimidi diff against 1.5.13 -- now PLAY returns the error from midiOutOpen
no sound is output trace:midi:ALSA_AddMidiPort OUT (14:Midi Through:kernel:0:Midi Through Port-0:a0002)
Did you read http://wiki.winehq.org/MIDI ? The app likely played silently...
http://bugs.winehq.org/show_bug.cgi?id=22978
--- Comment #10 from kapfell@gmx.de 2012-09-22 07:26:44 CDT --- (In reply to comment #9)
no sound is output
Did you read http://wiki.winehq.org/MIDI ? The app likely played silently...
Yes, you're right - I forgot to start the MIDI server. With a running server audio output from SharpEye v2.68 is heard. Thanks for your patch.
http://bugs.winehq.org/show_bug.cgi?id=22978
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Status|UNCONFIRMED |NEW CC| |00cpxxx@gmail.com Ever Confirmed|0 |1
--- Comment #11 from Bruno Jesus 00cpxxx@gmail.com 2012-10-01 10:41:57 CDT --- (In reply to comment #9)
Created attachment 41772 [details] mcimidi diff against 1.5.13 -- now PLAY returns the error from midiOutOpen
This patch fixes the issue in the game.
http://bugs.winehq.org/show_bug.cgi?id=22978
--- Comment #12 from Bruno Jesus 00cpxxx@gmail.com 2013-03-26 00:31:38 CDT --- Jörg, a similar version of this patch was commited, right?
https://bugs.winehq.org/show_bug.cgi?id=22978
--- Comment #13 from Austin English austinenglish@gmail.com --- Is this still an issue in current (1.7.36 or newer) wine? If so, please attach terminal output.
https://bugs.winehq.org/show_bug.cgi?id=22978
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #14 from Bruno Jesus 00cpxxx@gmail.com --- This bug is certainly fixed, the game starts fine and is playable in 1.7.50 (and 1.6).
https://bugs.winehq.org/show_bug.cgi?id=22978
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.51.
-
wine-bugs＠winehq.org