http://bugs.winehq.org/show_bug.cgi?id=17955
Summary: Eve online hanhs during random action Product: Wine Version: 1.1.18 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: puciek@gmail.com
Created an attachment (id=20302) --> (http://bugs.winehq.org/attachment.cgi?id=20302) Console log with wine git
Eve online hangs from time to time for no apparent reason, one time it is while moving stuff to cargo hold, other when i open transation window and other when i try to fit my ship. I can't really reproduce it beside waiting for it to crash. Also wine doesnt throw proper backtrace, only that its starting debugger but doesn't really do anything after that.
http://bugs.winehq.org/show_bug.cgi?id=17955
Kai Blaschke webmaster@thw-theorie.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |webmaster@thw-theorie.de
--- Comment #1 from Kai Blaschke webmaster@thw-theorie.de 2009-04-06 06:30:59 --- I'm not sure if this is the same problem I have with EVE, but I'll post my log later today. For me, EVE crashes sometimes when undocking, warping or jumping. According to console output, one thread crashes, and then the other remaining threads spam that RtlpWaitForCriticalSection timed out.
As there are no OpenGL related errors and mostly happens when loading ship models, textures or many UI sprites, I suspect this could be related to the heap management changes introduced with Quantum Rise (See http://www.eveonline.com/devblog.asp?a=blog&bid=613#a41).
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #2 from Tymoteusz Paul puciek@gmail.com 2009-04-06 09:41:20 --- This seem like possible cause, altho on me there is no typical "crash", so i think you should fill new bug report with your issue.
http://bugs.winehq.org/show_bug.cgi?id=17955
Marc-Olivier Barre marco@marcochapeau.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marco@marcochapeau.org
--- Comment #3 from Marc-Olivier Barre marco@marcochapeau.org 2009-06-29 05:36:33 --- I can confirm this one. I am very surprised at the number of people that rate this game platinum... Anyways, here are the symptoms:
- everything works just fine, just like any platinum game - after a while, random app crash
I'll try to grab some backtrace or whatever might be useful.
System is gentoo with an amd64. GPU is an X600 (radeon hd2900 XT) with the fglrx driver.
tested against wine 1.1.24
http://bugs.winehq.org/show_bug.cgi?id=17955
Alex alex--evil@yandex.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alex--evil@yandex.ru
--- Comment #4 from Alex alex--evil@yandex.ru 2009-07-04 14:19:22 --- Same situation on me, random crashes, usually then warping. Game hangs once in 20 minutes approximatly. Tried to decrease graphic settings to minimun, turn off sound - same crashes as before.
I'm using: Ubuntu 9.04 amd64, Core 2 Duo E6750, Geforce 8800 GTS (driver 180.53), 4 Gb RAM, Wine 1.1.25.
Hardware is stable, i'm sure of it
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #5 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-05 08:54:41 --- Ok I did more tests, and I did manage to prevent it from crashing by setting all the graphics options to the lowest, and running the game inside a desktop.
Then I turned the settings back on step by step to see if I could isolate the one that causes the issue. so far so good, everything is active except 3 of them:
- Bloom is set to none (there's
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #6 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-05 09:01:16 --- Ok I did more tests, and I did manage to prevent it from crashing by setting all the graphics options to the lowest, and running the game inside a desktop. This sounds obviously different from what Alex reported.
@Alex: do you run the game in a desktop ?
Then I turned the settings back on step by step to see if I could isolate the one that causes the issue. so far so good, everything is active except 3 of them:
- Bloom is set to none (there's a bug somewhere with this options... I get crappy lights, and upside down picture, bug no crash)
- HDR is off. - Shadows are off.
I'm going to stay a little while like that, then I'll try HDR and shadows again to see if it affects stability.
If all is fine even with shadows and HDR, then it might be related to the fact that the app doesn't run in a desktop: similar to the Alt+Tab issue, even when you don't press Alt+Tab.
oh, and btw, getting some useful logs is not that easy. I sometimes get a crash right after character selection if I turn on debug logging.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #7 from Kai Blaschke webmaster@thw-theorie.de 2009-07-05 09:44:08 --- Since Wine 1.1.25 and the latest EVE patch, the game crashes every few minutes, rendering it unplayable for me. Mostly, crashes happen when starting or ending a warp, docking or undocking, or when opening containers.
I managed to get a debug log from a crash, but I'm not sure if the crash had the same cause, as debug logging slowed down the game dramatically to about 4-5 seconds per frame.
I attached the last 1500 lins of the debug log (using WINEDEBUG="+relay,+seh,+tid"), which shows a heap allocation error in line 801, that seems to be the cause of the crash. That would explain why EVE crashes most frequently when it's loading or freeing resources.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #8 from Kai Blaschke webmaster@thw-theorie.de 2009-07-05 09:45:54 --- Created an attachment (id=22201) --> (http://bugs.winehq.org/attachment.cgi?id=22201) Debug log, crash happening in line 801
http://bugs.winehq.org/show_bug.cgi?id=17955
Alan Jackson ajackson@bcs.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ajackson@bcs.org.uk
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #9 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-06 12:55:37 --- Created an attachment (id=22222) --> (http://bugs.winehq.org/attachment.cgi?id=22222) A different crash log
I had a similar crash to the one above once (comment #8 by Kai Blaschke), So I'm not going to post a backtrace on this one. Although, I am completely unable to reproduce it now... go figure.
I also had another one, just as random, but that doesn't seem to happen while some ressources are loaded. That's the one you'll see in the attached logs (line 415).
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #10 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-06 13:04:42 --- Follow up on my comment #6:
I tested with HDR enabled. Except some graphical artifacts probably caused by the great quality of the fglrx driver, it seems to work like a charm.
With shadows enabled I got crash. not sure what it was exactly since I had no debug traces running at the time... how convenient. I'll give it another try.
Another thing that is worth mentioning: it is *extremely* easy to get wine+EVE to crash when some traces are running (while it is pretty stable without the traces, provided you have the right config). It kind of ruins all the fun of debugging... Could we get some hints from someone who has more wine insight on this issue ?
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #11 from Alex alex--evil@yandex.ru 2009-07-06 13:12:47 --- (In reply to comment #6)
@Alex: do you run the game in a desktop ?
Yes. I also turned off all graphics options in wine 1.1.25 - i had no influence on stability, game crashes anyway.
But now I installed wine 1.1.18 (oldest development version, available for Ubuntu 9.04) - it much more stable (1 crash in ~8 hours of play, with all graphics to max). I guess if i turn bloom, shadows and hdr off (as Marc-Olivier Barre advises), it will be stable. Testing that right now.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #12 from Henri Verbeet hverbeet@gmail.com 2009-07-06 15:18:07 --- (In reply to comment #10)
Another thing that is worth mentioning: it is *extremely* easy to get wine+EVE to crash when some traces are running (while it is pretty stable without the traces, provided you have the right config). It kind of ruins all the fun of debugging... Could we get some hints from someone who has more wine insight on this issue ?
Do those crashes have proper backtraces?
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #13 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-06 15:37:38 --- (In reply to comment #12)
(In reply to comment #10)
Another thing that is worth mentioning: it is *extremely* easy to get wine+EVE to crash when some traces are running (while it is pretty stable without the traces, provided you have the right config). It kind of ruins all the fun of debugging... Could we get some hints from someone who has more wine insight on this issue ?
Do those crashes have proper backtraces?
winedbg hangs after it is launched, and I am now pretty confident that any kind of wine logging make things worse. So not only don't we have proper backtraces, we don't seem to have any kind of tools that allows us to produce meaningful info either.
Is there somekind of magical tool we have not thought of ? What do we do when winedbg freezes ?
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #14 from Kai Blaschke webmaster@thw-theorie.de 2009-07-07 09:47:15 --- I played around a bit with winedbg to get a minidump or stack trace, but it's rather hard to achieve. EVE uses a loader process (EVE.exe, it displays the splash screen), which in turn loads the EVE client itself (ExeFile.exe). To debug EVE itself, run the client directly using:
winedbg "X:\path\to\EVE\bin\ExeFile.exe" /nosplash /noconsole
While entering the game, winedbg spits out hundreds of "C++ first chance exceptions", and breaks the execution. Enter "pass", and keep pressing the enter key. After a while, the game continues as usual. To get rid of excess "pass" commands, stop EVE using ctrl-c, and enter "cont". Otherwise, the program will terminate when it really crashes, and there is no chance of creating a minidump.
Play until EVE crashes, and the debugger will let you create a minidump. I have attached the register dump, backtrace and the respective minidump.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #15 from Kai Blaschke webmaster@thw-theorie.de 2009-07-07 09:48:42 --- Created an attachment (id=22241) --> (http://bugs.winehq.org/attachment.cgi?id=22241) Register dump and backtrace of a crash
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #16 from Kai Blaschke webmaster@thw-theorie.de 2009-07-07 09:50:09 --- Created an attachment (id=22242) --> (http://bugs.winehq.org/attachment.cgi?id=22242) Minidump for the crash above
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #17 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-10 16:21:42 --- Game seems to crash only after a few seconds in 1.1.25. Probably a new issue...
This is not helping us much...
And of course, this bug is still UNCONFIRMED which basically means that no dev will ever read these lines.
How do we get this status to NEW ?
http://bugs.winehq.org/show_bug.cgi?id=17955
Kai Blaschke webmaster@thw-theorie.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #18 from Kai Blaschke webmaster@thw-theorie.de 2009-07-10 18:27:54 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #19 from Kai Blaschke webmaster@thw-theorie.de 2009-07-10 18:40:02 --- Confirming is done by voting for it.
Marc-Olivier is right, this looks like a new issue in 1.1.25, and according to my backtrace and other crashes I experienced, these crashes might originate from some changes made in WineD3D since 1.1.24. After downgrading to 1.1.24, EVE runs rock stable again.
If I have some free time, I'll try to look deeper into the issue, using a Wine with debugging symbols to get a clue where the crash actually happens in the code.
I would also like to add that EVE requires some of the original d3dx_##.dll files to run properly. There might be an incompatibility between those DLLs and the latest changes made to Wine.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #20 from Rico kgbricola@web.de 2009-07-11 04:03:48 --- Did it work with an earlier version without any problems? Is the problem available on all architectures or only on x86_64? Has the amount of memory influence on the problem?
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #21 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-11 04:40:23 --- (In reply to comment #20)
Did it work with an earlier version without any problems? Is the problem available on all architectures or only on x86_64? Has the amount of memory influence on the problem?
Good questions Rico,
As far as earlier versions are concerned, I'm running 1.1.23 right now, and I had similar behaviors.
I can only test on 64 bit... reports on 32 bit could help, but it is very hard to tell if we're talking about the same crash or not.
From what I can tell from my observations, I'd say memory consumption, total
memory and CPU load can have an impact on how fast it'll crash. In game graphics details tuning seemed to be a dead end.
- Memory use : sometimes I get pretty quick crashes even if the cpu load is low... once I rebooted it worked much better. The only difference was that most of the cached memory had been freed by the reboot I guess.
- Total memory : I've got 4 Gigs. that's uncommon I guess. Could it be somehow related or is that far fetched ? Other apps on the system seem stable...
- CPU load : that's quite an obvious one IMO --> run the game, start something cpu hungry in the background, you'll probably get it to crash. Even better : run eve with some WINEDEBUG channels turned on. I seldom get it to run.
How are these 3 things related or are they meaningful, I'm not sure...
I'll also try to get a wine with debug symbols up to see what I can get from it. If I'm lucky, I might end up with a real backtrace to show :)
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #22 from Kai Blaschke webmaster@thw-theorie.de 2009-07-13 05:18:01 --- Here are the details of my box:
Running Gentoo Linux i686 (~x86 keyword, the "testing" branch) on an Intel Core 2 Duo E8400 with 4 GB RAM and a GeForce 9600 GT with 1 GB of RAM. System memory is error-free according to memtest86+, other apps run stable. I've got two EVE accounts, and run both side by side on this machine.
Running EVE with Wine 1.1.23 or 1.1.24 works great, just some very rare partial crashes (a Wine crash windows shows up, tells me the App crashed, but EVE continues to run sometimes, but with some "missing" parts, e.g. no ship models and icons are rendered anymore) after a long play time. Upgrading to Wine 1.1.25 changes that, so EVE crashes after a few minutes of play, mostly when warping or undocking, but also just sitting at a station. Crashes happen at the same ratio, no matter if I run one or two instances of the game client.
Memory use by EVE is quite high (on Windows too), being a problem for all EVE players with low amounts of memory. My memory usage rarely raises above 3 GB, even with two clients.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #23 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-13 06:28:27 --- (In reply to comment #22)
Here are the details of my box:
Running Gentoo Linux i686 (~x86 keyword, the "testing" branch) on an Intel Core 2 Duo E8400 with 4 GB RAM and a GeForce 9600 GT with 1 GB of RAM. System memory is error-free according to memtest86+, other apps run stable. I've got two EVE accounts, and run both side by side on this machine.
Ok, so you are running into the same crash even on a 32 bit gentoo... This seems to rule out the lib32 issue I was suspecting for 64 bit gentoo users.
Can you attach your emerge --info here, just in case I notice something ?
As for my latest findings : - I had a few dll overrides left from previous tweaks. I tried agan with wine 1.1.24 and a fresh .wine dir : no luck - I gave a try to wine 1.1.17 just in case. Well as expected, the graphic part was badly broken. the game could run, but would also crash randomly. couldn't get a clean trace so no clue if it is indeed the same crash.
I am currently jumping the shark : setting up my own 32 bit chroot env just to make real sure this is not some issue with the emul-linux-x86 packages.
Next plan is yet unknown... I am running out of ideas.
Did someone with better knowledge of the wine internals take a look at Kay's minidump ?
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #24 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-16 06:10:25 --- After some days fiddling around I finally found a new lead to follow... by inadvertence of course.
I happen to be re-coding the winejack driver (because honestly, it's a piece of copy-pasted crap). I have been testing my modifications until now by playing EVE. I still have no input for voice chat, but output works just good.
How is that related to our bug ? Well, since I stopped using the ALSA backend, I stopped seeing crashes. Yesterday I played nearly 8 hours straight doing all the things that usually end up with a crash at some point, including big combats... Could that be it ?
It sure needs more testing. Could the people hitting this issue try to disable ALSA completely ? You don't necessarily need to use the JACK backend (you won't be able to on Gentoo 64 unless you ask me how), you just need to disabled audio support in winecfg. It should do the trick.
Note: Disabling sound in the game is not enough since the driver gets loaded anyways.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #25 from Joxe stjoakim@gmail.com 2009-07-17 07:40:48 --- Created an attachment (id=22414) --> (http://bugs.winehq.org/attachment.cgi?id=22414) Terminal Output of EVE Online crash
The sound issue is a lead for sure, running Eve from a Terminal shows that the last error that pops up is PulseAudio related (can't remember exactly what it says). On the other hand I'm experiencing this bug with all audio drivers deactivated (from winecfg, poke at me if I've missed something ;). Running Eve from a Terminal then produces loads of errors, which I hope that I'm able to attach (first timer), that seem to have something to do with Direct 3D.
Just to try to get a fresh test result I completely purged my Wine installation and reinstalled Wine 1.1.25 with Eve as its only application. Going trough the minor tweaks (corefonts as an example) that's said to get it running smoothly and then running eve as: wine explorer /desktop=1680x1050 "C:\Program\CCP\EVE\eve.exe" to avoid the alt-tab bug. This gives me up to 20 minutes of play time before a crash occurs. CPU's on a steady 50% all the time and GPU doesn't reach any dangerous temperatures but crashes usually occurs when jumping, leaving stations etc.
I had Eve working perfectly on this system a few weeks ago but configuring Wine for another application seemed to destroy that possibility for me and I can't think of anything that I've done differently this time.
As said, I'm going to attach my Terminal output from start to crash since it includes some of the errors seen in the first post. Might as well post my specs too:
Intel E4700 Core 2 Duo 2.66GHz 2x1GB Corsair XMS2 RAM Gainward GeForce 8800GT Ubuntu Jaunty 9.04
http://bugs.winehq.org/show_bug.cgi?id=17955
Simon König simjoko@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |simjoko@gmail.com
--- Comment #26 from Simon König simjoko@gmail.com 2009-07-18 07:58:27 --- I can confirm this bug.
Also, I can confirm that I have yet to receive a crash when disabling the wine audio output completely.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #27 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-18 08:12:39 --- Ok, let me add something again:
All those who've had some form of success by disabling their audio drivers are invited to turn on as much graphical details as they can run on their hardware and test again.
I noticed that at the same time I switched to the jack audio driver, I had also lowered my graphical details... I did get some crashes in the end, but only after 8-12 hours of gameplay.
If I set to better graphic details, I can run the game for a shorter period of time before I get crash.
The graphics detail lead might not be entirely closed yet I'm afraid... *AND* Kai's crash backtrace does show d3dx9_35.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #28 from Simon König simjoko@gmail.com 2009-07-18 10:17:46 --- Sad to say, you're right. On the current git, which may 1.1.26 still, enabling the whole graphics shebang made EVE crash instantly when undocking. So the audio lead might not have been it.
(In reply to comment #27)
Ok, let me add something again:
All those who've had some form of success by disabling their audio drivers are invited to turn on as much graphical details as they can run on their hardware and test again.
I noticed that at the same time I switched to the jack audio driver, I had also lowered my graphical details... I did get some crashes in the end, but only after 8-12 hours of gameplay.
If I set to better graphic details, I can run the game for a shorter period of time before I get crash.
The graphics detail lead might not be entirely closed yet I'm afraid... *AND* Kai's crash backtrace does show d3dx9_35.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #29 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-18 12:02:24 --- (In reply to comment #28)
Sad to say, you're right. On the current git, which may 1.1.26 still, enabling the whole graphics shebang made EVE crash instantly when undocking. So the audio lead might not have been it.
Well yeah... Two things though :
- Does lowering the graphics detail on 1.1.26 help ? (I've only been playing with 1.1.24 due to the regressions from 1.1.25) - Is the behvior on 1.1.26 somehow different from what happened on 1.1.25 (ie. has the 1.1.25 issue been fixed ?) - Do you do your tests after a fresh boot ? (I know this sounds very windowish... but heh, it's wine !)
http://bugs.winehq.org/show_bug.cgi?id=17955
Joxe stjoakim@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stjoakim@gmail.com
--- Comment #30 from Joxe stjoakim@gmail.com 2009-07-19 07:38:14 --- Playing it with lowest possible graphics still produces the error, running from Terminal shows a message:
wine: Unhandled page fault on read access to 0x59ab14c8 at address 0x3b79435 (thread 001b), starting debugger... XIO: fatal IO error 11 (Resursen tillfälligt otillgänglig) on X server ":0.0" after 75 requests (75 known processed) with 0 events remaining. joxe@joxe-desktop:~$ fixme:x11drv:X11DRV_DestroyNotify window 0x1003a/4800005 destroyed from the outside
"page fault on read access" does it have anything to do with what files Wine wants to use? Running it from sudo just tells me that ~/.wine/ isn't owned by me. Seems like I'm having a different problem than the original poster (not the same error message).
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #31 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-19 07:52:58 --- (In reply to comment #30)
Playing it with lowest possible graphics still produces the error, running from Terminal shows a message:
wine: Unhandled page fault on read access to 0x59ab14c8 at address 0x3b79435 (thread 001b), starting debugger... XIO: fatal IO error 11 (Resursen tillfälligt otillgänglig) on X server ":0.0" after 75 requests (75 known processed) with 0 events remaining. joxe@joxe-desktop:~$ fixme:x11drv:X11DRV_DestroyNotify window 0x1003a/4800005 destroyed from the outside
"page fault on read access" does it have anything to do with what files Wine wants to use? Running it from sudo just tells me that ~/.wine/ isn't owned by me. Seems like I'm having a different problem than the original poster (not the same error message).
You probably are having a different problem, but we can't really tell can we. what wine version ? how does the crash happen ?
Anyways, you have an X error showing up on your output, so I suspect it's something completely different.
And for the record: - Running wine with sudo is extremely foolish and insecure - ~/.wine/ belongs to you, sudo runs things as root, so yes, it's a different user. - "page fault on read access" has nothing to do with access rights to files. It refers to an invalid access to a zone in memory.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #32 from Joxe stjoakim@gmail.com 2009-07-19 11:24:00 --- Yeah, I just did the sudo thing out from the blue to give it a shot really, not running Wine as sudo. Using Wine 1.1.26 during testing and the bug happens randomly between 1-15 minutes. There's another bug report here that resembles my problem a bit more so I'm going to try it instead. Hope you'll solve this bug!
http://bugs.winehq.org/show_bug.cgi?id=17955
Bob bob+wine@mcelrath.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob+wine@mcelrath.org
--- Comment #33 from Bob bob+wine@mcelrath.org 2009-07-19 17:20:11 --- I have repeatedly gotten this error on the console:
xeFile.exe: mixer.c:306: DSOUND_BufPtrDiff: Assertion `ptr2 < buflen' failed.
(yes I know the 'E' is missing, that is the way it is printed)
I don't get this error 100% of the time, but have gotten it repeatedly. Perhaps there are multiple bugs triggering a crash. At least this one gives a source file and line number. This is with wine 1.1.26 (Ubuntu 9.04 packages).
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #34 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-20 02:07:27 --- Just so things are clear and so we do not start mixing bugs, there is no need to report a crash with 1.1.25 or 1.1.26 here.
The crashes that happen just a few minutes after startup since 1.1.25 are described in http://bugs.winehq.org/show_bug.cgi?id=19219. Despite the fact that the faulty commit has been found, the bug is __not yet fixed in 1.1.26__.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #35 from Bob bob+wine@mcelrath.org 2009-07-20 02:33:17 --- It's impossible to tell from the symptoms ("random crash after running for a while") whether bug 19219 or bug 17955 are causing it...
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #36 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-20 02:55:37 --- (In reply to comment #35)
It's impossible to tell from the symptoms ("random crash after running for a while") whether bug 19219 or bug 17955 are causing it...
Well, yes. This is why testing bug 17955 against 1.1.25/1.1.26 serves absolutely no purpose.
Oh, and "for a while" can be quantified : bug 19219 it is only a few minutes (never more apparently), and only with 1.1.25 and 1.1.26 of course.
With 17955 it can be several hours.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #37 from Simon König simjoko@gmail.com 2009-07-20 07:10:09 --- (In reply to comment #29)
Well yeah... Two things though :
- Does lowering the graphics detail on 1.1.26 help ? (I've only been playing
with 1.1.24 due to the regressions from 1.1.25)
- Is the behvior on 1.1.26 somehow different from what happened on 1.1.25 (ie.
has the 1.1.25 issue been fixed ?)
- Do you do your tests after a fresh boot ? (I know this sounds very
windowish... but heh, it's wine !)
So, I did a lot more testing. Playing two clients on 2 virtual desktops for more than an hour did not give me any crash. Playing one client doing some pvp and such did not give me crash for hours. But then out of the sudden, it crashed. Repeating the actions before the crash did not trigger it again. This was without bloom, and all graphics settings set to lowest level. The graphics settings do not seem to make a difference though. Even with all settings maxed out I was not able to reproduce the crash any faster. For the record, I still do not have any audio drivers enabled for wine. Can't tell anything on the 1.1.25.
http://bugs.winehq.org/show_bug.cgi?id=17955
Mike Kazantsev mk.fraggod@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mk.fraggod@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=17955
N3o diafoirus@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |diafoirus@gmail.com
--- Comment #38 from N3o diafoirus@gmail.com 2009-08-08 13:55:44 --- I cant reproduce this bug in current version (1.1.27) many hours of playing without crash....
video Hardware /driver info:
NVIDIA UNIX x86 Kernel Module 185.18.31 Tue Jul 28 15:43:22 PDT 2009 EVGA 9800 GTX+ 512MB
http://bugs.winehq.org/show_bug.cgi?id=17955
Anton Vorobyov phoenix@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |phoenix@mail.ru
--- Comment #39 from Anton Vorobyov phoenix@mail.ru 2009-08-09 03:41:17 --- Same. Seems to be fixed in 1.1.27 release.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #40 from Alex alex--evil@yandex.ru 2009-08-09 14:26:04 --- Can confirm also, problem is gone in 1.1.27. Long live to Wine team!
http://bugs.winehq.org/show_bug.cgi?id=17955
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #41 from Austin English austinenglish@gmail.com 2009-08-09 15:20:06 --- Reported fixed...thrice.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #42 from Marc-Olivier Barre marco@marcochapeau.org 2009-08-20 15:07:23 ---
---- NOT FIXED PLEASE REOPEN ----
The crash that was fixed in 1.1.27 was the one introduced in 1.1.25. Our good old random crash is still there. Crashes just as well as with 1.1.24.
And for the record, to the people who reported this crash as fixed : a bug is fixed when:
- The cause of the crash has been found - A developer has written a proper patch - Eventually, the aforementioned patch has been made available in the bug report for people to test
Crashes don't disappear automagically just because a new version is out. Given the fact that so far no dev seems to have taken a look at this crash, I do not see any reasons why we should assume that wine fixed itself on its own.
---- NOT FIXED PLEASE REOPEN ----
http://bugs.winehq.org/show_bug.cgi?id=17955
Tymoteusz Paul puciek@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |
--- Comment #43 from Tymoteusz Paul puciek@gmail.com 2009-08-20 15:10:15 --- Reopening
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #44 from Tymoteusz Paul puciek@gmail.com 2009-08-20 15:13:27 --- But i must say that sometimes crashes do get fixed "by accident" while fixing other bug so i would hold back a bit with yelling ;)
http://bugs.winehq.org/show_bug.cgi?id=17955
drachu@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |drachu@gmail.com
--- Comment #45 from drachu@gmail.com 2009-08-24 02:01:54 --- I can confirm that for me version 1.1.27 still crashes, however it happens much less frequently, testing version 1.1.28 soon, maybe its fixed there.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #46 from Anton Vorobyov phoenix@mail.ru 2009-08-24 02:31:25 --- Yes, I experience these crashes too. Other source of crashes has been resolved, but issue described in this bug report still occurs. I'm using 1.1.28.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #47 from Anton Vorobyov phoenix@mail.ru 2009-08-26 06:52:24 --- Since commit batch dated 20, 21 or 24 aug i do not get these crashes anymore - i.e. issue seems to be fixed in current git.
Let's wait .29 and get final confirm from other users to close this...
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #48 from Marc-Olivier Barre marco@marcochapeau.org 2009-08-26 08:17:35 --- (In reply to comment #47)
Since commit batch dated 20, 21 or 24 aug i do not get these crashes anymore - i.e. issue seems to be fixed in current git.
Let's wait .29 and get final confirm from other users to close this...
Ok, I see I'm going to need to spell it out.
For most easily reproducible bugs one can just "wait" for a magical fix to appear out of nowhere. Because of it's reproducible nature, it's easy to test if the bug is gone or not, and eventually trace down which commit fixed it (thus getting the knowledge of what to do if it "magically" reappears...)
Here, we are facing a Random Bug (TM). One of those which trigger is not obvious/straight-forward (like "clicking somewhere"). Some people - including me - have reported that under some circumstances, the bug was not reproducible until several hours had passed (I pushed that to over 12).
This means, unless we get a clean explanation, reason of failure and patch for this, we will never know if it was really fixed for sure.
This takes us back to issue number one : could a wine dev please help us track this down ?
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #49 from Anton Vorobyov phoenix@mail.ru 2009-08-26 10:56:03 --- Crash occurred for me one time each 2-6 hours. With new git version - eve was running more than 25-30 hours without any crashes. I believe i can operate probabilities not worse than average IT guy, and from my perspective - chance is less than 2-5% that crash is still here. And that's the reason why i left note to wait until new tag is made and couple of other guys confirm this.
Actually resources of Wine developers and community are limited. What you described - is right way to do, but it's utopia unless YOU get it in your own hands and find exact repro steps and reason why we experienced these crashes. In real world when working on big projects (my current job is QA Team Lead in the biggest casual games company - Oberon Media) like Wine developers can't spend their time finding source of each and every bug, especially when reporter has no clue by which module it is caused.
To keep bug tracker clean it's good idea to close such 'random' issues if nobody gets it for some time (time is chosen dependant upon available qa resources and other project specifics).
I've just added one bit of statistics to the whole picture. When other guys (who experienced that crash before) will also tell that it seems to be fixed - bug may be safely closed. In the end of the day, you always have an option to reopen it.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #50 from Marc-Olivier Barre marco@marcochapeau.org 2009-09-06 17:32:13 --- (In reply to comment #49)
Actually resources of Wine developers and community are limited. What you described - is right way to do, but it's utopia unless YOU get it in your own hands and find exact repro steps and reason why we experienced these crashes. In real world when working on big projects (my current job is QA Team Lead in the biggest casual games company - Oberon Media) like Wine developers can't spend their time finding source of each and every bug, especially when reporter has no clue by which module it is caused.
Your position as a QA team lead in a company that builds proprietary closed source software is probably not relevant, really... I'm pretty sure Microsoft themselves have a lot of QA guys too. Do they help ? Obviously... no. That being said...
Wine resources are limited, sure, I agree. I work on free softwares myself, and time is hard to find when this is not your day job.
As for the exact reproduction steps : - Compile something big, make it last long, burn CPU and memory (compiling wine is a good start :) ) - Once you've done that, close all windows and programs, grab a beer and relax. - Click on your EVE icon. Crash should occur in the next 5 minutes.
This at least should make the crash reproducible and help test if it is magically gone or not... As of 1.1.29, it's not.
Now as far as helping to debug wine is concerned, before this even happens, we would need tools to do that. As stated *many times* in this bug report, running wine properly and getting a proper back-trace is near impossible. Unless someone has the knowledge to make a suggestion that wasn't tested yet.
I would be willing to help with wine development, but I just do not have the time and resources to improve the debugger... sorry.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #51 from Vitaliy Margolen vitaliy@kievinfo.com 2009-09-06 19:41:28 --- (In reply to comment #50) This is offtopick, please more such "useful" information to forum/mailing list.
I would be willing to help with wine development, but I just do not have the time and resources to improve the debugger... sorry.
What's wrong with gdb?
http://bugs.winehq.org/show_bug.cgi?id=17955
Rob rob.ss.bass@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rob.ss.bass@gmail.com
--- Comment #52 from Rob rob.ss.bass@gmail.com 2009-10-23 16:23:21 --- I can confirm that I am experiencing this exact bug in 1.1.31 under Mint 7 (Ubuntu 9.04) running EVE in a virtual desktop. I've been unable to catch any error messages and the debugger seems to hang when EVE crashes. On crash I occasionally get graphic corruption, but this could be due to the fact I'm using ATI.
I'm new to Linux and don't know how to do a backtrace or any other debugging, I will try to learn how and then repost what I find here.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #53 from Rob rob.ss.bass@gmail.com 2009-10-24 04:47:33 --- Created an attachment (id=24308) --> (http://bugs.winehq.org/attachment.cgi?id=24308) Post-Hang Terminal Dump
This is a dump of my entire terminal buffer after EVE hung. The crash message is: wine: Unhandled page fault on write access to 0xb4a00400 at address 0x7509aa2 (thread 001c), starting debugger...
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #54 from Rob rob.ss.bass@gmail.com 2009-10-25 23:54:07 --- Error still occurs in Wine 1.1.32 and core affinity doesn't seem to affect it. Still unable to get useful information from backtrace beyond the following:
Crash on Character loading Occurs randomly but frequently: err:ntdll:RtlpWaitForCriticalSection section 0x7eb31ce0 "gdiobj.c: GDI_level" wait timed out in thread 001c, blocked by 002e, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7e423920 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 002e, blocked by 001c, retrying (60 sec) wine: Critical section 7eb31ce0 wait failed at address 0x7bc35019 (thread 001c), starting debugger...
Random Crash While Playing occurs randomly but sporadically; hex addresses change: fixme:imm:NotifyIME NI_CLOSECANDIDATE wine: Unhandled page fault on read access to 0xb3d63000 at address 0xb7d73896 (thread 001c), starting debugger...
Do you guys think these are the same bug? I'm not sure if I should open a new bug for the character loading issue.
I've saved a number of error logs I can attach if anyone thinks it would help. Unfortunately I don't know how to extract any further information about the crashes beyond outputting the error data to a file, any suggestions?
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #55 from Rob rob.ss.bass@gmail.com 2009-11-04 00:29:36 --- Created an attachment (id=24542) --> (http://bugs.winehq.org/attachment.cgi?id=24542) Info from Wine Debugger
A little bit more info that I was able to squeeze from the debugger.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #56 from Rob rob.ss.bass@gmail.com 2009-11-12 04:07:45 --- I've noticed that before a hang there seems to be an increase in hard disk activity.
http://bugs.winehq.org/show_bug.cgi?id=17955
Karsten Elfenbein kelfe@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kelfe@gmx.de
--- Comment #57 from Karsten Elfenbein kelfe@gmx.de 2009-11-12 12:06:39 --- this "x11drv_main.c: X11DRV_CritSection" thread blocking seems to affect a lot of other games as well
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #58 from Rob rob.ss.bass@gmail.com 2009-11-12 15:59:39 --- (In reply to comment #56)
I've noticed that before a hang there seems to be an increase in hard disk activity.
It also might be worth noting that the problem occurs sooner (less than 10 minutes as opposed to 1hr+) if I do not reboot the X server after a crash and if the crash occurs multiple times without resetting the X server, on the third launch it will always corrupt the graphics at the login screen.
http://bugs.winehq.org/show_bug.cgi?id=17955
Mike Kazantsev mk.fraggod@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|mk.fraggod@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #59 from Rob rob.ss.bass@gmail.com 2009-11-13 04:13:30 --- (In reply to comment #58)
(In reply to comment #56)
In addition I get this result from the debugger on every crash: X Error of failed request: BadPixmap (invalid Pixmap parameter) Major opcode of failed request: 54 (X_FreePixmap) Resource id in failed request: 0x320002f Serial number of failed request: 253 Current serial number in output stream: 255
The only thing that changes is the hex address. Unfortunately I don't know what it means nor what I should do next.
http://bugs.winehq.org/show_bug.cgi?id=17955
--- Comment #60 from N3o diafoirus@gmail.com 2010-07-11 23:24:15 --- --- On Eve Online Reporting : Not occur on 1.2.rc7 (6 hrs+ of play) ---
http://bugs.winehq.org/show_bug.cgi?id=17955
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED
--- Comment #61 from Austin English austinenglish@gmail.com 2010-07-12 10:35:02 --- Reported fixed.
http://bugs.winehq.org/show_bug.cgi?id=17955
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #62 from Alexandre Julliard julliard@winehq.org 2010-07-30 12:56:57 --- Closing bugs fixed in 1.3.0.
-
wine-bugs＠winehq.org