https://bugs.winehq.org/show_bug.cgi?id=39477
Bug ID: 39477 Summary: Wine crashes with alsa/pulseaudio in Star Trek Online Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: rob@sandersmail.eu Distribution: ---
Created attachment 52612 --> https://bugs.winehq.org/attachment.cgi?id=52612 crash trace
The game works quite well for around 30-45 min then it crashes. It usually happens when you change the zone. It's the only game which crashes for me - so it might be something game specific.
I'm using crossover-14.1.10-1.i386
Crash trace attached.
https://bugs.winehq.org/show_bug.cgi?id=39477
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #1 from Austin English austinenglish@gmail.com --- Please report Crossover issues to Codeweavers.
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #2 from Rob Sanders rob@sandersmail.eu --- Really? Codeweavers/crossover bits are not crashing. Wine is....
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #3 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Rob Sanders from comment #2)
Really? Codeweavers/crossover bits are not crashing. Wine is....
It might still have to do with the differences between plain Wine and CrossOver's Wine. Also, the bug might have been fixed since Wine ~1.7.25.
Feel free to reopen if you can reproduce with plain Wine 1.7.53 or newer.
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #4 from Rob Sanders rob@sandersmail.eu --- Thanks Matteo. I will try to reproduce it with 1.7.53.
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #5 from Rob Sanders rob@sandersmail.eu --- Created attachment 52618 --> https://bugs.winehq.org/attachment.cgi?id=52618 screenshot of crash window
Hi,
I managed to crash the game with Wine version shipped with Fedora 23 (I believe fedora ships wine-staging) - ver: 1.7.52
Unfortunately it crashed in such a random way I was unable to save the log as the log window was unresponsive.
I managed to take a screenshot tho.
https://bugs.winehq.org/show_bug.cgi?id=39477
Rob Sanders rob@sandersmail.eu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52612|0 |1 is obsolete| |
--- Comment #6 from Rob Sanders rob@sandersmail.eu --- Created attachment 52619 --> https://bugs.winehq.org/attachment.cgi?id=52619 trace with wine staging 1.7.52 shipped with Fedora 23
Managed to crash it again. This time I've got a backtrace.
https://bugs.winehq.org/show_bug.cgi?id=39477
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |aeikum@codeweavers.com Resolution|NOTOURBUG |--- Ever confirmed|0 |1
--- Comment #7 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Rob Sanders from comment #6)
Created attachment 52619 [details] trace with wine staging 1.7.52 shipped with Fedora 23
Managed to crash it again. This time I've got a backtrace.
Thank you. Can you try to check whether it does still crash also with the ALSA backend? You should be able to select it via the HKCU/Software/Wine/Drivers/Audio registry key (see http://wiki.winehq.org/UsefulRegistryKeys for details).
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #8 from Rob Sanders rob@sandersmail.eu --- Hi Matteo,
I will try to reproduce it with the registry changes you mentioned.
FYI I also opened codeweavers ticket id: 1044876 for this issue as suggested by Austin.
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #9 from Rob Sanders rob@sandersmail.eu --- I'm afraid the same problem. The backtrace with forcing alsa via the registry is the same as for crossover's version of wine attached to this ticket.
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #10 from Andrew Eikum aeikum@codeweavers.com --- Thanks for testing, Rob. Could you get a debug log with the channels from http://wiki.winehq.org/Sound?
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #11 from Rob Sanders rob@sandersmail.eu --- Hi,
I've run the game with the following debug options:
WINEDEBUG=+tid,+seh,+mmdevapi,+winmm,+driver,+msacm,+midi,+dsound,+dsound3d,+xaudio2,+xapofx,+dmusic,+mci,+pulse,+oss,+alsa,+coreaudio,+timestamp
The log is over 3.6GB uncompressed. I uploaded the compressed version to my server at: http://priv.sandersmail.eu/wine/wine_sound_debug.log.tar.xz
It's around 144MB.
Please let me know if there's anything else I can do to help with debugging this issue.
Regards, Rob
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #12 from Andrew Eikum aeikum@codeweavers.com --- Oh! I've seen this before. The problem is you're running out of memory:
mmap() failed: Cannot allocate memory
Wine reserves a bunch of memory, and then STO is likely using lots of memory. On top of that, Pulse tries to allocate 64 MB of memory, which is a lot. In your particular arrangement, this allocation fails and shows the above message and then crashes. None of this is really a "bug," per se, we've just run out of 32-bit address space.
You can work around this by asking Pulse to use less memory. In </etc/pulse/daemon.conf>, see these lines:
; enable-shm = yes ; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB
In the past, we've recommended setting shm-size-bytes to 1048576. You can find (mostly useless) descriptions of these options in the pulse-daemon.conf(5) manpage.
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #13 from Rob Sanders rob@sandersmail.eu --- Hi Andrew,
The last thing I was expecting was the system to run out of memory. I've got 32GB of RAM in each of the machine I used for testing and pulse never really used a lot.
I didn't think about 32bit limitations considering that system is 64bit. I guess wine and all audio libraries are limited by 32bit.
Surprisingly STO it's the only game where I saw this behaviour, but mind you it's the only game I played under wine in the last year.
I will change pulse settings and will see if I can still reproduce it.
Thank you very much for your suggestions!
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #14 from Andrew Eikum aeikum@codeweavers.com --- Yeah. 32-bit processes like STO are limited to about 4 GB of address space. Wine takes a lot, the game takes a lot, and then pulseaudio wants to allocate a contiguous 64 MB chunk. It's not too surprising that that fails in some modern video games.
If the game has a 64-bit version, you could try that in a 64-bit build of Wine, which would let you use all 32 GB of RAM. But probably just changing the PA settings will fix it.
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #15 from Rob Sanders rob@sandersmail.eu --- (In reply to Andrew Eikum from comment #14)
Yeah. 32-bit processes like STO are limited to about 4 GB of address space. Wine takes a lot, the game takes a lot, and then pulseaudio wants to allocate a contiguous 64 MB chunk. It's not too surprising that that fails in some modern video games.
If the game has a 64-bit version, you could try that in a 64-bit build of Wine, which would let you use all 32 GB of RAM. But probably just changing the PA settings will fix it.
I've been testing it for the last few days and wine stopped crashing. The game still occasionally crash without a backtrace - probably because the game is running out of memory rather than pulseaudio.
Thank you very much for your help!
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #16 from Andrew Eikum aeikum@codeweavers.com --- Do you get any output at all on the terminal when the game crashes? Wine does not handle OOM conditions gracefully, but I'd at least be curious to confirm that that's the problem.
If you're satisfied with this situation, we could probably close this bug, but I'm just looking for a little more info about the problem you're having.
https://bugs.winehq.org/show_bug.cgi?id=39477
--- Comment #17 from Rob Sanders rob@sandersmail.eu --- Finally after many tries I managed to get something. Not sure how useful this is:
err:heap:HEAP_ValidateInUseArena Heap 0x4e40000: invalid in-use arena magic 00000000 for 0x585ed60 Assertion 'pthread_mutex_lock(&m->mutex) == 0' failed at pulsecore/mutex-postix.c:90, function pa_mutex_lock(). Aborting.
https://bugs.winehq.org/show_bug.cgi?id=39477
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #18 from winetest@luukku.com --- Could you retest with more recent wine?
https://bugs.winehq.org/show_bug.cgi?id=39477
Stefanescu A stefanescu.a@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefanescu.a@mail.com
--- Comment #19 from Stefanescu A stefanescu.a@mail.com --- Works with wine 7.0 staging and ALSA.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla