http://bugs.winehq.org/show_bug.cgi?id=15485
Robert Förster Dessa@gmake.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dessa@gmake.de
keymone keymone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |keymone@gmail.com
Anton Vorobyov phoenix@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |phoenix@mail.ru
Aigars Mahinovs aigarius@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aigarius@gmail.com
Marc-Olivier Barre marco@marcochapeau.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marco@marcochapeau.org
--- Comment #53 from Anton Vorobyov phoenix@mail.ru 2009-04-09 13:41:46 --- There seems to be some kind of dependency on graphics shown in-game.
1) EVE under wine crashes on login screen 2) EVE under wine crashes on character selection screen 3) EVE under wine doesn't crash while being inside the station (Amarr VIII (Oris) - Emperor Family Academy in my case, ships used to check - retribution, capsule, prorator) 4) EVE under wine crashes outside that station and on Amarr V planet
The only thing that unifies crash cases - they occur when you're in space w/o limited vision (i.e. inside the cube with texture which is used to show space background, i don't know special term for that, and as far as i understand eve uses them for loginscreen too to show space image).
In cases with crash it occurs with 5-20% chance, in 3rd case i already made ~thousand of focus switches so i'm pretty sure in my statistics.
Debian Squeeze, Acer 5920 (NVIDIA 8600GT + 180.41 driver), wine from today's git snapshot.
--- Comment #54 from Anton Vorobyov phoenix@mail.ru 2009-04-09 13:47:41 --- Ok, i've got the crash inside that station, but it seems that in station it's repro rate significantly lower than outside, thus it gives us clue that it's probably something d3d-related (sound was disabled).
--- Comment #55 from N3o diafoirus@gmail.com 2009-04-25 20:34:23 --- Hi pilots...
in the current version (1.1.20) I cant reproduce this bug (congrats guys ^^).. I did many switch focus, and all works very well, no fps drop, just perfect ^^..
We need confirm if this bug is solved =)...
Fly safe...
--- Comment #56 from Robert Förster Dessa@gmake.de 2009-04-26 04:23:33 --- no, it isn't fixed, still getting stuff like that: wine: Unhandled page fault on read access to 0x0000006c at address 0x1006152d (thread 001e), starting debugger...
--- Comment #57 from keymone keymone@gmail.com 2009-04-28 03:51:08 --- confirming it's not fixed kubuntu 9.04, wine 1.1.20
--- Comment #58 from N3o diafoirus@gmail.com 2009-04-28 09:58:07 --- Well if isn't fixed, How I can reproduce it ?... I need tips ^^... Maybe it reproduce in special situations, for example, In station, In a pos, etc I did all my test inspace...
Fly safe...
--- Comment #59 from keymone keymone@gmail.com 2009-05-01 03:48:19 --- N3o,
run EVE and do ALT-TAB back and forth between eve and other applications while being in wild space(it really happens less frequently in stations)
--- Comment #60 from Stephen Eilert spedrosa@gmail.com 2009-05-02 22:51:05 --- It appears to be happening less frequently, but it still crashes for me as well.
I am not sure of what kind of logging would be helpful to attach to this issue.
--- Comment #61 from N3o diafoirus@gmail.com 2009-05-04 19:40:19 --- Hi pilots..
Yes, isnt fixed, I test this bug with a robot, yes, I developed a small program to simulate the alt+tab (with counter), the results:
1) Crash appear normally aprox 50 -> 70 alt+tab combination, in secuence mode VS the older wine version (at the 1st alt+tab, the game crash)
2) Crash appear normally aprox 90 -> 150 alt+tab combination, in full random secuence mode VS the older wine version (at the 1st alt+tab, the game crash)
notes:
all test maded in a full toon POS, with camera at sun direction (to force hdr and other effects), 30 windows open in-game, local chat aprox 200 pilots, and 4 desk app opened (OpenOffice, aMSN, Mumble, Firefox (this playing a Youtube HD video in fullscreen mode),
Ingame effects all set to high... 1680x1050 resolution @ 24 Bits.
Resume:
The bug appear less frequent in 1.1.20 version VS the older version....
My test machine:
AMD Phenom X4 9950, 4GB RAM Corsair Dominator 1066Mhz, Slackware 12.2 (32bits), Evga 9800 GTX+ in PCIe 2 mode, nVIDIA UNIX x86 Kernel Module 180.51,
Fly safe...
--- Comment #62 from Simon König simjoko@gmail.com 2009-05-26 07:20:33 --- (In reply to comment #61)
Hi pilots..
Yes, isnt fixed, I test this bug with a robot, yes, I developed a small program to simulate the alt+tab (with counter), the results:
Hey there! Would you mind attaching that test util to this bug report?
I wonder if the patch today will help with that matter.
-> "An exception error will no longer be generated when switching between full screen and windowed mode."
I don't know if this might be related to our problem at all, but hope never dies on my end :)
Saying this, problem is still present on 1.1.22.
--- Comment #63 from Aigars Mahinovs aigarius@gmail.com 2009-07-02 12:51:45 --- Still there in wine 1.1.24 with EVE 6.13.94168. Crashed on the second context switch at the login screen. (Note that you don't need an account to test this as the crash happens even before the login information is entered)
--- Comment #64 from Marc-Olivier Barre marco@marcochapeau.org 2009-07-06 14:56:17 --- Well...
Confirmed again for wine 1.1.25 and EVE 6.13.94168
This bug has been there for nearly a year and confirmed by many. The bug status is still NEW. Doesn't something seem wrong ?
Did any dev even look at this ?
--- Comment #65 from William Waghorn willw@litany.me.uk 2009-07-06 21:48:27 --- (In reply to comment #64)
This bug has been there for nearly a year and confirmed by many. The bug status is still NEW. Doesn't something seem wrong ?
Did any dev even look at this ?
I for one did look into this (scroll back, you'll see I'm not the only one who tried investigating). I even had a look through the relevant bits of the stackless python source. At the time my own conclusion was that there was a race condition in the closed-source Eve client related to a missed lock in their stackless python implementation. I'd expect the bug can happen on Windows too, but like any race condition, timing is everything. Wine can implement all the same bugs as Windows, but implementing all the same timings is kind of unrealistic. Sorry.
I tried whinging to CCP, emphasising that wine is likely to be highlighting a bug in their client which may well manifest on Windows too, but got the old "Wine on Linux is not supported" boilerplate. Ho hum.
As I see it, there are two events which may force a resolution to this bug. First, a CCP developer may encounter the problem on a Windows system and recognises it for what it is. To be honest, I think that's highly unlikely. The second possibility is that any CCP developer tries EVE under wine. Once.