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
Daniel Santos daniel.santos@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.santos@pobox.com
Lisa Denia eiffel56@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eiffel56@gmail.com
Philipp N. betadog@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|betadog@gmx.net |
evanh evanh@clear.net.nz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |evanh@clear.net.nz
--- 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.
--- Comment #66 from N3o diafoirus@gmail.com 2009-07-18 23:35:42 --- confirming in 1.1.26
--- Comment #67 from Daniel Santos daniel.santos@pobox.com 2009-07-24 02:12:00 --- Would somebody mind seeing if the cursor patches will resolve this problem? I can't see it for sure in the log snippet I examined, but this is possibly related to bug #18371
http://glest.codemonger.org/files/wine/cursor-work-20090723.tbz2
You will need to compile wine from git (or these patches may work with fuzz against 1.1.26). Download the above link and extract it into a new directory.
From your wine sources directory, run:
git am -3 <file>.txt
on each of the files in cursor-work-20090723.tbz2 and then compile and please post your results (if the bug still happens).
--- Comment #68 from Lisa Denia eiffel56@gmail.com 2009-07-26 20:59:23 --- Another solution could be applying the attached patch. If using it, EVE won't know if it has lost or gained focus. This does not fix the problem itself, but it won't trigger anymore.
The patch has 2 drawbacks: 1. EVE would stop rendering if it loses focus, so it will render all the time with that patch causing full system load all the time. We could extend the hack a bit more by disabling Direct3D9 rendering probably. Very very hacky...
2. As EVE will render all the time, even if you change focus you will see EVE in the background. The hack could be extended to minimize the window every time we lose focus, EVE wouldn't be visible anymore.
--- Comment #69 from Lisa Denia eiffel56@gmail.com 2009-07-26 21:58:37 --- Created an attachment (id=22637) --> (http://bugs.winehq.org/attachment.cgi?id=22637) No focus notifications
--- Comment #70 from Anton Vorobyov phoenix@mail.ru 2009-08-07 16:45:34 --- I used .27 version released today, applied all patches, eve doesn't even launch.
First time it wrote huge log (log1), on each subsequent startup - smaller one (log2).
--- Comment #71 from Anton Vorobyov phoenix@mail.ru 2009-08-07 16:48:27 --- Created an attachment (id=22892) --> (http://bugs.winehq.org/attachment.cgi?id=22892) 1st log output of wine with cursor patches
--- Comment #72 from Anton Vorobyov phoenix@mail.ru 2009-08-07 16:50:38 --- Created an attachment (id=22893) --> (http://bugs.winehq.org/attachment.cgi?id=22893) 2nd log: output of wine with cursor patches on subsequent attempts to launch EVE
--- Comment #73 from Anton Vorobyov phoenix@mail.ru 2009-08-07 16:52:07 --- Forgot to specify in comment 70 - i applied cursor patch set from comment 67
--- Comment #74 from Anton Vorobyov phoenix@mail.ru 2009-08-16 03:50:51 --- There're couple of workarounds mentioned in bug #16136:
1: --- event.c~ 2008-11-07 11:09:33.000000000 -0500 +++ event.c 2008-11-20 13:10:15.000000000 -0500 @@ -685,7 +685,7 @@ if (hwnd == GetForegroundWindow()) { TRACE( "lost focus, setting fg to desktop\n" ); - SetForegroundWindow( GetDesktopWindow() ); + //SetForegroundWindow( GetDesktopWindow() ); } } } 2: Focus loss and/or gain events are completely disabled by this patch: http://bugs.winehq.org/attachment.cgi?id=17410
1st does work for me, although it may not work for some machines.
--- Comment #75 from evanh evanh@clear.net.nz 2010-01-28 05:26:07 --- I believe this is the same bug as http://bugs.winehq.org/show_bug.cgi?id=14282