http://bugs.winehq.org/show_bug.cgi?id=31595
Bug #: 31595 Summary: Unreal Tournament 3 crashes on launch Product: Wine Version: 1.5.2 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: kisak42@gmail.com Classification: Unclassified
This is a two part bug: I have been unable to launch Unreal Tournament 3 Black on Steam using any release of wine newer than 1.5.1 (wine 1.5.2-1.5.12 as of this writing). Wine 1.5.1 runs well enough. When joining multiplayer campaigns via a direct ip connection, while joining before the start of the first match is reliable and staying in the campaign as the matches progess, I can not rejoin a game in progess with the in-game error "Sorry, you are not authorized by STEAM to play this game at this time." It appears that this error plagues everybody across the board. I rarely make bug reports, so please let me know what I can provide to assist in troubleshooting this bug.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #1 from kisak42@gmail.com 2012-09-01 15:35:15 CDT --- I am a gentoo 64 bit user using a 32 bit wine prefix. I have an AMD Bulldozer 3.6 / nVidia GTX460 with the 304.43 binary blob.
http://bugs.winehq.org/show_bug.cgi?id=31595
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #2 from Bruno Jesus 00cpxxx@gmail.com 2012-09-01 17:19:35 CDT --- Please, try again in wine 1.5.12. If the problem persists you should run a regression test to find the problem. Take a look at http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=31595
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #3 from kisak42@gmail.com 2012-09-02 17:14:35 CDT --- Alright, here goes ...
I ran the regression test and discovered a couple things. On failure I observed:
fixme:dbghelp:elf_search_auxv can't find symbol in module wine: Unhandled exception 0xc0000409 at address 0x12235a7 (thread 004f), starting debugger...
In comparison this was observed on a successful start of the game.
fixme:dbghelp:elf_search_auxv can't find symbol in module fixme:d3d:resource_check_usage Unhandled usage flags 0x8. ... etc.
The git bisect finished with the output:
[98815f399c1e37e1e33e5712e4e74d4c56f9ad78] winecoreaudio.drv: Use device GUIDs as keys.
So that leads me to believe that shortly after elf_search_auxv the game initializes the Bink video introduction. It should be noted that the intro of UT3 uses a separate audio pipeline from the game engine, which is openal and depending on settings, the openal section can be set to bypass wine's audio subsystem (into the system-installed openal).
Unfortunately, my setup includes JACK + alsa loopback device, so I killed jackd, set all the audio selections in winecfg to [In:/Out:/(none)] HDA ATI SB - ALC889 Analog. Using both winecfg from 1.5.1 and 1.5.2 and testing the combinations of bisected git and 1.5.2 produced no working scenarios. For that little bit of extra confirmation, wine 1.5.12 + manually selected analog output has confirmed audio output from winecfg and crashes UT3.
http://bugs.winehq.org/show_bug.cgi?id=31595
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com Regression SHA1| |98815f399c1e37e1e33e5712e4e | |74d4c56f9ad78
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #4 from Andrew Eikum aeikum@codeweavers.com 2012-09-04 10:05:35 CDT --- As you're using Linux, I'm a little surprised at your CoreAudio bisect result. Can you attach a debug log with the channels from http://wiki.winehq.org/Sound?
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #5 from kisak42@gmail.com 2012-09-04 11:44:09 CDT --- Created attachment 41570 --> http://bugs.winehq.org/attachment.cgi?id=41570 verbose log of launching UT3 with the bisected wine-git
I attached the requested log, I omitted Steam launching from the log. I am running kernel 3.4.9, which has alsa 1.0.25. I am using the snd_hda_intel kernel module with only realtek and hdmi support compiled in with it.
Quick facts: hw:0 is the alsa loopback device hw:1 is a secondary audio card (CA0106) (should not be involved) hw:2 is the primary analog card hw:3 is hdmi, and if detected at all hw:4 is a mic on a webcam. elf_search_auxv is on line 863. Unhandled exception on line 2146. JACK was not running during this log and winecfg should still be set to point to hw:2.
Please let me know if you want this repeated with 1.5.12.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #6 from Andrew Eikum aeikum@codeweavers.com 2012-09-04 12:48:00 CDT --- There's nothing really suspicious in there. Are you presented with a backtrace in the crash dialog or in your terminal output? Another log with the same channels and also "+seh,+timestamp" might give more info. If you've got time, doing another bisect might be useful, as I think something went wrong with the one you did earlier (winecoreaudio isn't compiled on your system, so it can't be the bad commit).
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #7 from kisak42@gmail.com 2012-09-04 15:33:40 CDT --- Created attachment 41573 --> http://bugs.winehq.org/attachment.cgi?id=41573 verbose log of launching UT3 with the bisected wine-git +seh
No, I am not seeing a full stack trace. Attached is the same as before with requested channels added. elf_search_auxv is on line 1318, unhandled exception on line 2613.
I am going to rerun the git bisect.
http://bugs.winehq.org/show_bug.cgi?id=31595
kisak42@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #41573|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=31595
kisak42@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|98815f399c1e37e1e33e5712e4e |e87cb774d131963d2642d075977 |74d4c56f9ad78 |571585ec5da8d
--- Comment #8 from kisak42@gmail.com 2012-09-04 15:48:35 CDT --- I apologize for any confusion I may have caused, having never used git bisect before, I misinterpreted the feedback from it and missed the last iteration of the test, we're indeed looking at: e87cb774d131963d2642d075977571585ec5da8d mmdevapi: Use device GUIDs as unique identifiers.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #9 from Andrew Eikum aeikum@codeweavers.com 2012-09-05 09:22:19 CDT --- I installed this game through Steam this morning, and it doesn't crash for me. Did you build Wine yourself? What version of GCC are you using? I'm wondering if you're possibly triggering another instance of Bug 22316. Can you try rebuilding latest wine-git (or latest wine release, either is fine) with both "-mstackrealign" and "-mincoming-stack-boundary=2" in your CFLAGS?
I believe configure will fail if they're specified at configure-time. I do it at the build step, like this: $ ./configure $ make depend $ make CFLAGS+="-mstackrealign -mincoming-stack-boundary=2" CXXFLAGS+="-mstackrealign -mincoming-stack-boundary=2"
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #10 from kisak42@gmail.com 2012-09-05 10:53:02 CDT --- My system-wide wine is built through portage, and I have been taking the easier path by using Playonlinux's prebuilt wine for troubleshooting and to use misbehaving apps. The git bisect is built by me. My system-wide gcc is 4.6.3 for the march=bdver1 optimization.
On to the relevent bit: $ make clean $ CC="ccache gcc -m32" ./configure --verbose --disable-tests $ make depend -j8 $ make CFLAGS+="-mstackrealign -mincoming-stack-boundary=2" CXXFLAGS+="-mstackrealign -mincoming-stack-boundary=2" -j8 $ env WINEPREFIX="/home/kisak/.PlayOnLinux//wineprefix/UT3" WINEDEBUG=+tid,+mmdevapi,+winmm,+driver,+midi,+dsound,+dsound3d,+dmusic,+mci,+oss,+alsa,+coreaudio ~/wine-git/wine /home/kisak/.PlayOnLinux/wineprefix/UT3/dosdevices/c:/Program\ Files/Steam/Steam.exe -no-dwrite -> launch UT3 resulted in a successful launch. So I continued with a git bisect reset and repeated from the top, and it failed with: wine: Unhandled exception 0xc0000409 at address 0x12235a7 (thread 004f), starting debugger... I honestly didn't know what to make of that, so I recompiled it again ,,, it failed again ... did a git pull and recompiled ... same result. Should I do another git bisect with -mstackrealign -mincoming-stack-boundary=2?
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #11 from Andrew Eikum aeikum@codeweavers.com 2012-09-05 11:29:44 CDT --- The c0000409 STATUS_STACK_BUFFER_OVERRUN error is the error we've been dealing with.
It sounds like we're on the right track, but I feel like things are getting pretty unclean at this point. We should try resetting to a baseline.
I would suggest resetting and cleaning your Wine tree to match the latest wine-git, do a build with the switches, and re-install Steam into a new wineprefix. You can copy the UT3 files from the old prefix's steamapps folder so you don't have to re-download them. I usually trigger the download in Steam, then quit Steam and copy the files, and then start Steam again and let it finish the installation process.
As an aside, the "-m32" switch at configure-time seems unusual to me. Wine's build system should take care of that kind of thing for you. I'm wary of overriding Wine's build system without a reason for it.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #12 from kisak42@gmail.com 2012-09-05 13:34:33 CDT --- Okay, I removed ccache and created a new 32bit wine prefix, installed steam with msiexec /I ...steaminstaller.msi. Switched away from using system-wide wine at this point. I copied the common folder in steamapps, deleted ~/wine-git and ran: $ git clone git://source.winehq.org/git/wine.git wine-git/ $ cd ~/wine-git && ./configure $ make depend $ make CFLAGS+="-mstackrealign -mincoming-stack-boundary=2" CXXFLAGS+="-mstackrealign -mincoming-stack-boundary=2" -> switched to the testing terminal and ran: $ env WINEPREFIX="/home/kisak/.PlayOnLinux//wineprefix/UT3_testing" WINEDEBUG=+tid,+mmdevapi,+winmm,+driver,+midi,+dsound,+dsound3d,+dmusic,+mci,+oss,+alsa,+coreaudio ~/wine-git/wine /home/kisak/.PlayOnLinux/wineprefix/UT3_testing/dosdevices/c:/Program\ Files/Steam/Steam.exe -no-dwrite
The only involvement Playonlinux has done with this wineprefix is the few mouse clicks to make a 32bit wineprefix, no hidden winetricks in the background.
Told steam to install UT3, it detected the pre-existing files, told steam to launch UT3, rejected all the one-time installers, UT tried to launch and stopped rendering on the screen (transparent). I killed UT3 remotely, steam wouldn't give me the option of trying to re-run the one-time installers, so I nuked the wineprefix and repeated, this time allowing the four one-time installers run, and we're back to the same unhandled exception.
As an aside, the "-m32" switch at configure-time seems unusual to me. Wine's build system should take care of that kind of thing for you. I'm wary of overriding Wine's build system without a reason for it.
This is directly from instructions given to me via http://wiki.winehq.org/RegressionTesting If this is not the intended instructions, then the wiki needs to be updated for those who actually read the details.
I hope this is a sufficiently clean environment to continue. Because this is a fresh wineprefix, it is pointing to system default for audio, which is the alsa loopback device.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #13 from Andrew Eikum aeikum@codeweavers.com 2012-09-05 14:03:47 CDT --- Yeah, that's enough.
When I installed UT3, I let it install the MS Runtime and PhysX, but canceled the DirectX installer and the other installer (I've forgotten what it was, but I'm pretty sure I canceled it). I can't imagine that those are causing your problem, though.
Unfortunately, I am running out of ideas. It's interesting that you did get it to work once. I suspect it's some kind of build or library incompatibility. This looks a lot like Bug 29431, where you get dsound crashes in strange places. But unfortunately, setting those compiler flags didn't fix it for you.
I'm starting to get out of my bounds of knowledge here... Does your computer have a stack size limit set? What does 'ulimit -s' output? On my computer, I get 8192.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #14 from kisak42@gmail.com 2012-09-05 16:25:38 CDT --- Created attachment 41582 --> http://bugs.winehq.org/attachment.cgi?id=41582 endless loop sample
ulimit -s outputs 8192.
I broadened my test environment to include another 64bit gentoo build with a simple alsa setup, to my surprise (and your confirmation) UT3 came right up with no problem. So, I set about eliminating the differences between them and I found it on the first try; I built snd-aloop as a module, modprobed it, restarted steam, and tried to launch UT3. It fell into an endless loop on launch, I attached a sample of the loop with no particular start or end. This behavior leads me to believe that the alsa loopback device is missing something that is found in a normal sound device and wine's audio subsystem may not have cared before the GUID commit. I did not modify any config to include the alsa loopback device, just it's existence is sufficient. Please modprobe snd-aloop and let me know if you see similar behavior.
Specs on the second build: Gentoo 64bit, Phenom 9950 (2.6GHz), nVidia 8800GT x2 with the 295.71 binary blob, gcc 4.5.4, wine-git with the extra stack options (32bit wineprefix), gnome 2.x
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #15 from kisak42@gmail.com 2012-09-05 18:19:01 CDT --- That seemingly endless loop is not relevent to this bug, it occurs when the game runs as it should. Please disregard it.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #16 from Andrew Eikum aeikum@codeweavers.com 2012-09-10 09:21:41 CDT --- I tested after loading snd_aloop and it still works fine for me.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #17 from kisak42@gmail.com 2012-09-11 17:59:52 CDT --- I went back and retested on my second box and whatever problem it is having, it's a hung launch of UT3 that occurs about 30% of the time. Regardless of what that problem might be, it's definitely not the 409 error and just muddled my testing. Thank you for trying that failed lead. I will be more complete in my testing in the future.
I am currently out of ideas as to how to proceed as the probability rises that the flaw is outside of wine ... this might be anything from compiler optimizations in alsa-libs to a bug in gcc 4.6.x for bdver1. Part of this which I do not understand is why wine versions that are not built on my system reliably work or fail as expected (the same as wine-git).
If there are any suggestions as to the next course of action, please let me know.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #18 from Andrew Eikum aeikum@codeweavers.com 2012-12-13 09:14:17 CST --- Hi kisak,
Did you ever get this resolved? Have you been able to determine if this is a Wine bug, or something wrong with your setup?
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #19 from kisak42@gmail.com 2012-12-13 17:21:03 CST --- Mr. Eikum, Thank you for your continued interest in this issue. I tested UT3 against 1.5.19 a few days ago and it still fails.
My current thoughts on this matter is that there may be some code in a dependency that is sensitive to the change made between 1.5.1 and 1.5.2 and the GCC 4.6.3 / bdver1 optimization on my system. There has been no indication of a misconfiguration in my system outside of wine. The reason I suspect a dependency of wine is that pre-built wine packages from PlayOnLinux are equally affected. I'm thinking that the bdver1 optimization across my system causes a fringe use-case that is not reproducible unless a bdver1 or bdver2 processor is used in the test.
As a side note: the recent improvements in the nvidia binary blob has caused UT3 to become much more playable on wine 1.5.1.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #20 from kisak42@gmail.com 2013-03-25 15:32:11 CDT --- Created attachment 44014 --> http://bugs.winehq.org/attachment.cgi?id=44014 GDB backtrace attempt
I had a try at capturing a backtrace of the regression. This test was made using wine commit e87cb774d131963d2642d075977571585ec5da8d. ./capture contains: #!/bin/bash env WINEPREFIX="/home/kisak/.PlayOnLinux//wineprefix/UT3" WINEDEBUG=+tid,+mmdevapi,+winmm,+driver,+midi,+dsound,+dsound3d,+dmusic,+mci,+oss,+alsa,+coreaudio ~/wine-git/wine /home/kisak/.PlayOnLinux/wineprefix/UT3/dosdevices/c:/Program\ Files/Steam/Steam.exe steam://run/13210 sleep 3 UT3pid=`pgrep UT3.exe` gdb --pid $UT3pid
I could have kept going, but they all read about the same, I stopped when I got a gui message "Wine program crash" "Internal errors - invalid parameters received" I'm not sure how else to proceed except for putting start and stop warn messages around all of the changes in the commit. I'm running the 3.7.10 kernel with nvidia-drivers 313.26 these days.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #21 from kisak42@gmail.com --- Created attachment 46889 --> http://bugs.winehq.org/attachment.cgi?id=46889 UT3 winedbg backtrace
It's been a while and I've been tinkering with my desktop, after dropping mate 1.6 and dropped nvidia-drivers-319.76, wine 1.7.8, and several misc. packages I tried to run ut3 on a newer wine again and to my surprise, winedbg gave me a backtrace, attached.
http://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #22 from kisak42@gmail.com --- sigh ... sorry for the bother, looks like I spoke too soon and that backtrace appears to be unrelated to this bug report.
https://bugs.winehq.org/show_bug.cgi?id=31595
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://store.steampowered.c | |om/app/13210/ CC| |focht@gmx.net Summary|Unreal Tournament 3 crashes |Unreal Tournament 3 (Steam) |on launch |crashes on launch
--- Comment #23 from Anastasius Focht focht@gmx.net --- Hello folks,
this this problem still present? Please retest with recent Wine, preferably Wine 1.7.17+.
Reading the comments it looks like you have a broken host setup. No one other could reproduce this.
Regards
https://bugs.winehq.org/show_bug.cgi?id=31595
--- Comment #24 from kisak42@gmail.com --- (In reply to Anastasius Focht from comment #23)
this this problem still present? Please retest with recent Wine, preferably Wine 1.7.17+.
Yes, this issue has the same behavior with Wine 1.7.17. I am currently out of ideas and do not know how to capture a relevent backtrace as the crash is not occuring in a section of wine that dumps to winedbg and the stall from attaching gdb crashes the game in another, unrelated way.
Reading the comments it looks like you have a broken host setup. No one other could reproduce this.
If the host setup is broken, why would it reliably work with wine 1.5.1 (steam now needs a patch to launch with a working version)?
From what I can tell, only Mr. Eikum has attempted to reproduce this issue and
other simular systems here do not have the problem, only my primary desktop. I'm willing to test in any manner requested, I just do not have the experience to proceed.
https://bugs.winehq.org/show_bug.cgi?id=31595
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
--- Comment #25 from mrdeathjr28@yahoo.es --- In my case works in wine 1.7.25
https://www.youtube.com/watch?v=LA0RYsDzNtg
https://bugs.winehq.org/show_bug.cgi?id=31595
kisak42@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |ABANDONED
--- Comment #26 from kisak42@gmail.com --- While I can not play this game at all, due to the major surge in better running games and that this appears to be an edge case affecting apparently no other users, I will be closing this bug report to remove it from the overloaded bug maintainers. I applogize for my lack of troubleshooting skills as I never was able to get any concrete information as to what has gone wrong here.
There are multiple systems here with effectively the same userspace, and only my main desktop was affected.
I have never claimed to be a programmer and have the upmost respect for those with clearer minds. Also, I am available for any further testing which may shed light on what happened in this case.
https://bugs.winehq.org/show_bug.cgi?id=31595
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #27 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org