http://bugs.winehq.org/show_bug.cgi?id=22033
Summary: World of Warcraft Crashes on statup Product: Wine Version: 1.1.40 Platform: x86 OS/Version: Solaris Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: jason.whipp@gmail.com
Created an attachment (id=26793) --> (http://bugs.winehq.org/attachment.cgi?id=26793) Console and Wowerror output
OS: OpenSolaris snv_134 Wine: 1.1.40 (Compiled)
When launching WoW, I get a screen that looks like it's going to start, but then immediately crashes. I can here the sound from the app running, but no video and the wowerror crash screen comes up, follow by the wine "This program had an error" dialog. I've appended the the console and wowerror output into an attachment.
In the OSOL contrib repo, there is a binary version of wine 1.0.1. With this version, WoW runs fine, except there's no sound (the contrib version doesn't detect any sound drivers).
Help appreciated, very willing to try recommendations and get more output to you if need be.
I've also tried using WoW in full screen, with a virtual desktop in full screen and in windowed mode.
http://bugs.winehq.org/show_bug.cgi?id=22033
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2010-03-13 20:47:21 --- Not blocker: http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity Looks like a video driver bug to me - since you running WoW in opengl mode.
http://bugs.winehq.org/show_bug.cgi?id=22033
Jase Whipp jason.whipp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|World of Warcraft Crashes |World of Warcraft Crashes |on statup |on startup
--- Comment #2 from Jase Whipp jason.whipp@gmail.com 2010-03-14 13:01:11 --- Just tested with NVidia 195.30, same result.
When I saw the output, I'd normally agree, however with the app working fine with 1.0.1, I had my doubts.
I have a Linux workstation (Fedora 12 x86_64) running 1.1.38, NVidia 195.30 which runs flawlessly, so I am suspecting this is a Wine OpenSolaris specific issue.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #3 from Jase Whipp jason.whipp@gmail.com 2010-03-14 13:03:14 --- Also, sorry about the blocker status, I must've missed setting that when I submitted the bug.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #4 from Austin English austinenglish@gmail.com 2010-03-14 15:10:16 --- (In reply to comment #2)
Just tested with NVidia 195.30, same result.
When I saw the output, I'd normally agree, however with the app working fine with 1.0.1, I had my doubts.
Please run a regression test: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=22033
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmail.com
--- Comment #5 from Roderick Colenbrander thunderbird2k@gmail.com 2010-03-21 16:53:03 --- The game crashes in the opengl driver (libGL.so). We don't do any opengl emulation (we directly forward it all) if you are running the game in opengl mode. It looks like an Nvidia driver issue. As a workaround try running the game in Direct3D mode.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #6 from Jase Whipp jason.whipp@gmail.com 2010-03-21 23:59:26 --- Repeated the same test with no -opengl param to Wow.exe. Runs fine under 1.0.1 in both modes (though performance is not as great in D3D mode). Under 1.1.40, I receive the error indicated in the report with -opengl, with out opengl:
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr febdc863 err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 7f8c9851 There's a string of errors supplied before these two lines, full output is in the attachment "wow-gl-errors.text".
I understand that wine doesn't provide the rendering, but that is not the issue. We have a working app in wine v 1.0.1, and not working 1.1.40 with the same video drivers, in fact, with no OS modification what so ever. My theory? Something between wine 1.0.1 and 1.1.40 broke direct rendering on Open Solaris under Wine.
Also, not that it is a major point, but the same test system also runs compiz, but I had it disabled during the testing. I REALLY doubt there is a video driver or vendor opengl issue here.
To the regression test, I respectfully decline, I've had other issues, some of which I have commented in other bug reports, compiling wine. The wine 1.1.40 is from the ASwine package available on sunfreepacks.com. Compiled by someone with a lot more knowledge of the compilation process.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #7 from Jase Whipp jason.whipp@gmail.com 2010-03-22 00:01:09 --- Created an attachment (id=26965) --> (http://bugs.winehq.org/attachment.cgi?id=26965) Full error output from Wine 1.1.40 running Wow.exe in DirectX mode
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #8 from Roderick Colenbrander thunderbird2k@gmail.com 2010-03-22 04:00:03 --- Perform a regression test. Perhaps solaris is suffering from the virtual memory issue we had on Linux before. That would explain the out of memory messages. It would be the Solaris version of http://bugs.winehq.org/show_bug.cgi?id=13335.
http://bugs.winehq.org/show_bug.cgi?id=22033
Johann johann@myrkraverk.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johann@myrkraverk.com
--- Comment #9 from Johann johann@myrkraverk.com 2010-05-02 11:16:57 --- Workaround:
Downgrade to 1.1.29, WoW works in that version with sound in builds 115 and later.
http://bugs.winehq.org/show_bug.cgi?id=22033
Johann johann@myrkraverk.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org
--- Comment #10 from Johann johann@myrkraverk.com 2010-05-02 19:32:09 --- Regression testing between 1.1.29 and 1.1.35 gives the following results:
1aa749d9e7ee54f221373ccb2b47bcb31ef6533f is first bad commit commit 1aa749d9e7ee54f221373ccb2b47bcb31ef6533f Author: Alexandre Julliard julliard@winehq.org Date: Tue Oct 27 19:06:48 2009 +0100
libwine: Reserve some low memory space even without a preloader.
:040000 040000 c6cbdf6fa3f40c287da32a6a3906d4d0ad7c5909 9fee74fb30f8b9bb7ccc3905c65607d13aabdf8b M libs
http://bugs.winehq.org/show_bug.cgi?id=22033
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.2.0 Severity|normal |major
--- Comment #11 from Roderick Colenbrander thunderbird2k@gmail.com 2010-05-03 03:08:42 --- I already feared it was related to the memory code. While (Open)Solaris isn't the most popular Wine platform, I think we want this to work fine for 1.2 and this bug looks quite serious.
http://bugs.winehq.org/show_bug.cgi?id=22033
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Component|-unknown |loader
http://bugs.winehq.org/show_bug.cgi?id=22033
Albert Lee trisk@forkgnu.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |trisk@forkgnu.org
--- Comment #12 from Albert Lee trisk@forkgnu.org 2010-05-03 12:20:57 --- This is probably a duplicate of #22023.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #13 from Johann johann@myrkraverk.com 2010-05-03 13:44:05 --- Created an attachment (id=27693) --> (http://bugs.winehq.org/attachment.cgi?id=27693) pmap before crash
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #14 from Johann johann@myrkraverk.com 2010-05-04 03:53:33 --- Truss log, 77M: http://raven.myrkraverk.com/~johann/truss-wow.log Compressed, 1.2M: http://raven.myrkraverk.com/~johann/truss-wow.log.7z
http://bugs.winehq.org/show_bug.cgi?id=22033
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #15 from Jerome Leclanche adys.wh@gmail.com 2010-05-04 04:01:35 --- (In reply to comment #14)
Truss log, 77M: http://raven.myrkraverk.com/~johann/truss-wow.log Compressed, 1.2M: http://raven.myrkraverk.com/~johann/truss-wow.log.7z
Links are dead. Please attach the compressed version on bugzilla.
http://bugs.winehq.org/show_bug.cgi?id=22033
Matt Lewandowsky matt@greenviolet.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matt@greenviolet.net
--- Comment #16 from Matt Lewandowsky matt@greenviolet.net 2010-05-04 04:10:39 --- (In reply to comment #15)
The compressed version is too large for bugzilla. I suppose that's the reason for external hosting. :)
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #17 from Johann johann@myrkraverk.com 2010-05-04 04:11:59 --- Created an attachment (id=27703) --> (http://bugs.winehq.org/attachment.cgi?id=27703) Patch against 1.1.43: #if 0's commit 1aa749d
http://bugs.winehq.org/show_bug.cgi?id=22033
Matt Lewandowsky matt@greenviolet.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #18 from Matt Lewandowsky matt@greenviolet.net 2010-05-04 05:12:07 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #19 from Matt Lewandowsky matt@greenviolet.net 2010-05-04 05:17:57 --- Conversing with Johann on IRC, it was discovered that the bad patch is at least the cause for bug 22023 and a few apps in my test suite which have been problematic the past dozen builds or so.
As for the "solution", I can't say. But I can say Johann's patch against 1.1.43 makes a good half dozen apps in my test suite work as they should and used to on OpenSolaris.
Hopefully tomorrow I'll find the chance to test some more recently-broken apps on OpenSolaris and FreeBSD (the problem has been seen both places).
Was 1aa749d9e7ee54f221373ccb2b47bcb31ef6533f tested on platforms other than Linux?
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #20 from Alexandre Julliard julliard@winehq.org 2010-05-04 05:39:12 --- (In reply to comment #19)
Was 1aa749d9e7ee54f221373ccb2b47bcb31ef6533f tested on platforms other than Linux?
It was made specifically for Solaris, that code path isn't even executed on Linux. It's needed for .NET support.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #21 from Matt Lewandowsky matt@greenviolet.net 2010-05-04 05:47:37 --- (In reply to comment #20)
OK. I haven't actually taken more than the most cursory glance at the patch yet. I just noted that it worked... ;)
I guess that means the similar behavior I'm observing on FreeBSD is another bug. So ignore me on that for now. :)
Is there any easy answer to this problem? .NET vs almost anything 3D is a tough choice to make...
http://bugs.winehq.org/show_bug.cgi?id=22033
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |6tsukiyami9@gmail.com
--- Comment #22 from Austin English austinenglish@gmail.com 2010-05-04 10:53:32 --- *** Bug 22023 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #23 from Johann johann@myrkraverk.com 2010-05-04 16:23:00 --- Workaround/Fix:
Add LD_PRELOAD=libmapmalloc.so to the environment.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #24 from Matt Lewandowsky matt@greenviolet.net 2010-05-04 17:02:41 --- (In reply to comment #23)
LD_PRELOAD is never a solution. :( Adding -lmapmalloc to LDFLAGS is a better solution.
The question is probably currently "Is mapmalloc the best choice on Solaris, since there are a half-dozen mallocs available with the OS, and perhaps even bypassing those would be sane?"
mapmalloc pretty much is malloc with mmap instead of sbrk. I've not found numbers showing how much it improves on the standard malloc (and where it fails in comparison), but I can't imagine it being THAT much faster.
http://developers.sun.com/solaris/articles/multiproc/multiproc.html is probably a good starting point for how the different mallocs work on Solaris.
I'm somewhat partial to mtmalloc, myself, but I've not tested wine with it yet, and I don't know if the heap size would be detrimental.
Perhaps the interim fix could be to document that one may need to include -lmapmalloc in LD_FLAGS on Solaris builds at this time?
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #25 from Maurizio Oliveri 6tsukiyami9@gmail.com 2010-05-05 10:04:50 --- Ijust tried to build wine .43 adding -lmapmalloc to LD_FLAGS, and altough 3D apps run (I didn't try any .NET one though) there are some serious performance issues. I tried running 'time winecfg', and... using -lmapmalloc: Real: 24,83s User: 4,45s System: 0,81s Percent: 21% Cmd: winecfg reverting the patch: Real: 5,64s User: 0,48s System: 0,49s Percent: 17% Cmd: winecfg Both times, winecfg didn't have to update/create the .wine directory, I've removed it before both tests, used winecfg to create ~/.wine, then run winecfg again with the time command, closing the window as soon as it popped up. Of course, this also happens when running any application, the startup time is really long.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #26 from Johann johann@myrkraverk.com 2010-05-05 13:55:49 --- Yes, mapmalloc is a serious performance hog. Using /usr/lib/firefox/libjemalloc.so gives much better performance.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #27 from Matt Lewandowsky matt@greenviolet.net 2010-05-06 18:40:47 --- (In reply to comment #26) mapmalloc may be a performance hog, but so far my testing is indicating that:
1) "It works."
2) It's available as a core piece of Solaris (even before 9, which is the oldest version anyone should even think of using Wine on...).
jemalloc doesn't meet #2, which is kind of important. And I'm seeing various issues with concurrent allocations, which mapmalloc does not support (and therefore works across the board so far). Also, if jemalloc was argued as Wine's default allocator, it would not likely be usable for Wine on OS X, according to various comments in the sources.
My testing is ongoing. This is just a summary for the bug's sake of ongoing conversations on IRC.
http://bugs.winehq.org/show_bug.cgi?id=22033
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.2.0 |---
--- Comment #28 from Alexandre Julliard julliard@winehq.org 2010-06-16 08:07:04 --- Broken Solaris malloc, won't be fixed for 1.2.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #29 from Maurizio Oliveri 6tsukiyami9@gmail.com 2010-06-16 08:35:48 --- (In reply to comment #28)
Broken Solaris malloc, won't be fixed for 1.2.
Guess we'll have to check out the git repo and manually revert the 1aa749d9e7ee54f221373ccb2b47bcb31ef6533f patch to make EVERY game (at least, the ones using 3D) work until this is fixed... I've been doing this since 1.1.33, so it's no big news for me, but you may want to put this info somewhere visible so the Solaris users will be able to use wine for something different than Office :)
By the way... Is this bug in the 1.3 milestone now??
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #30 from Jase Whipp jason.whipp@gmail.com 2010-06-16 10:44:19 --- Keep in mind, this bug is OpenSolaris related, not Solaris 10, there's a fair amount of difference. I've also been following OSOL development which seems to have stagnated, I'd agree delaying this bug due to that fact.
I also think a note on the wiki about the patching would be good for those running OSOL.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #31 from Johann johann@myrkraverk.com 2010-06-16 18:35:14 --- I'll just add that I've been using -lumem with UMEM_OPTIONS=backend=mmap with good results for WoW.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #32 from Albert Lee trisk@forkgnu.org 2010-06-17 23:28:36 --- (In reply to comment #30)
Keep in mind, this bug is OpenSolaris related, not Solaris 10, there's a fair amount of difference. I've also been following OSOL development which seems to have stagnated, I'd agree delaying this bug due to that fact.
The default malloc is largely unchanged from S10, so this bug should also affect it. Not sure what you're basing "stagnated" on.
I also think a note on the wiki about the patching would be good for those running OSOL.
Agreed, although this will be less of a problem once the /contrib and other popular packages have a workaround.
http://bugs.winehq.org/show_bug.cgi?id=22033
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|loader |-unknown Summary|World of Warcraft Crashes |World of Warcraft Crashes |on startup |on startup (due to broken | |Solaris malloc()) Severity|major |normal
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #33 from Maurizio Oliveri 6tsukiyami9@gmail.com 2010-06-18 07:44:37 --- Why is this set as normal ("for an application crash or other issue") now? It still does affect a wide range of apps (thus should be major)... Maybe the list of affected apps should be updated too
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #34 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-18 07:50:19 --- (In reply to comment #33)
Why is this set as normal ("for an application crash or other issue") now? It still does affect a wide range of apps (thus should be major)... Maybe the list of affected apps should be updated too
Because now it implies that it's not really a Wine bug, but having a workaround could be considered possible.
http://bugs.winehq.org/show_bug.cgi?id=22033
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |1aa749d9e7ee54f221373ccb2b4 | |7bcb31ef6533f
http://bugs.winehq.org/show_bug.cgi?id=22033
Ken Mays maybird1776@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maybird1776@yahoo.com
--- Comment #35 from Ken Mays maybird1776@yahoo.com 2011-08-27 12:49:33 CDT --- (In reply to comment #34)
(In reply to comment #33)
Why is this set as normal ("for an application crash or other issue") now? It still does affect a wide range of apps (thus should be major)... Maybe the list of affected apps should be updated too
Because now it implies that it's not really a Wine bug, but having a workaround could be considered possible.
Can you confirm if this is an issue with Wine 1.3.27?
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #36 from Ken Mays maybird1776@yahoo.com 2011-08-30 05:07:41 CDT --- (In reply to comment #0)
Created an attachment (id=26793)
--> (http://bugs.winehq.org/attachment.cgi?id=26793) [details]
Console and Wowerror output
OS: OpenSolaris snv_134 Wine: 1.1.40 (Compiled)
When launching WoW, I get a screen that looks like it's going to start, but then immediately crashes. I can here the sound from the app running, but no video and the wowerror crash screen comes up, follow by the wine "This program had an error" dialog. I've appended the the console and wowerror output into an attachment.
In the OSOL contrib repo, there is a binary version of wine 1.0.1. With this version, WoW runs fine, except there's no sound (the contrib version doesn't detect any sound drivers).
Help appreciated, very willing to try recommendations and get more output to you if need be.
I've also tried using WoW in full screen, with a virtual desktop in full screen and in windowed mode.
OS: Solaris 11 Express snv_151 Wine 1.3.27 (Compiled) Tested App: World of Warcraft: Cataclysm patch 4.2: Rage of the Firelands.
You can resolve this ticket.
Solaris can use "-lumem" instead of malloc (older implementations) due to the multithreaded/SMP design of the OS. So, you could patch for Solaris 10/11 (sunos5) to use '-lumem' in this case for better scalability.
Sound for Wow on Solaris 10/11 is just dependent on if the contributing person enabled sound or not in the contributed Wine package.
Don't bother with the fancier methods if they are not default system libs.
http://bugs.winehq.org/show_bug.cgi?id=22033
--- Comment #37 from Austin English austinenglish@gmail.com 2013-11-13 16:52:35 CST --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.6 or newer) wine? If so, please attach the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=22033
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED
--- Comment #38 from Austin English austinenglish@gmail.com --- Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=22033
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #39 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=22033
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |malicorne@chez.com
--- Comment #40 from Austin English austinenglish@gmail.com --- *** Bug 40783 has been marked as a duplicate of this bug. ***
-
wine-bugs＠winehq.org