Hi, since last update i have 5 client crashes. It happens mostly in space.

Unhandled exception: page fault on read access to 0x57737c67 in 32-bit code (0x1e0fee3e).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:1e0fee3e ESP:0033af60 EBP:0033af78 EFLAGS:00010202( R- -- I - - - )
EAX:27fffffb EBX:00000005 ECX:2f737c68 EDX:ffffffff
ESI:00000000 EDI:00000005
Stack dump:
0x0033af60: 00000001 01e0df08 1e1a36a7 1e1a36cd
0x0033af70: 00000005 00000005 00000000 1e01d246
0x0033af80: 00000000 2d477830 0033b054 ffffffff
0x0033af90: 0033afd4 2b6c1fe0 1e01b9a6 01e0df08
0x0033afa0: 2d477830 00000000 00000001 04fd0de4
0x0033afb0: 00000083 001752c0 01e0df08 001b0fd0
Backtrace:
=>0 0x1e0fee3e in python27 (+0xfee3e) (0x0033af78)
0x1e0fee3e: testb$0x1,0x4(%eax,%ecx,1)
Modules:
....

I just loaded Escalation and encountered very similar issues. I was in a trade hub. Undocked and crashed. Came right back, and crashed immediately again. Third time, I was able to get two warps away before crashing at a gate. Going to fiddle with some graphics settings and see if there's anything that won't crash.

confirming the problem on Gentoo amd64 with wine-1.5.2

As far as i can see on the forums, windows users don't suffer from this problem. Has anyone an idea how to determine if this is a wine or an eve-client bug?

You are not authorized to view this bug report

Well, I'm not used to bug reporting in EVE, it seems that this issue is currently viewable only by me, isn't ?

Anyway, here's my url : https://bugs.eveonline.com/mybugreports.asp?Action=View&ID=133469

Also, screenshot : http://pix.toile-libre.org/upload/original/1335298019.png

...
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x01ff ignored
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:dbghelp:elf_search_auxv can't find symbol in module
wine: Unhandled page fault on read access to 0x57737c67 at address 0x1e0fee3e (thread 0041), starting debugger...

One guy in the Linux ingame channel reports that it dosen't crasch with folowing:

Suri Abrams > Two GTX 570s in SLI with 295.4 drivers and the most recent wine you can get on Arch.

Not sure what if anything what it means seems alot of you got the same driver version.

@Laurent: It crashs with 295.40 for the tengu here. Just getting the loading animation and then the client freezes (not the computer). Tornado is working fine here. Loading, seems to be fine and rotating it... works nicely.
//edit: Legion and Proteus also crashs here.
//edit2: Could it be, that its working with the Tornado here as I checked it yesterday and its still in cash, while I never checked the other T3 ships? Maybe that the reason, why it seems to be somewhat random which T3 are crashing the client?

As workaround, I suggest everyone to open the map (so that models are not actually displayed) and dock/undock/fly to safety.

Also, there's nothing wrong with dozens of people confirming bug with winehq as well, or at least until somewhere there actually confirms the bug, enough activity on the bug report by a lot of people might see movement. The problem does appear to be UI related and I think there was work there for Inferno.

We know it's not a windows issue, so either wine or eve is broken, hopefully it's a quick fix, I live up north and avoiding T3s is hard!

Cheers,
Maq

fixme:d3d:resource_check_usage Unhandled usage flags 0x8
fixme:d3d:resource_check_usage Unhandled usage flags 0x8
fixme:d3d:resource_check_usage Unhandled usage flags 0x8
fixme:d3d:resource_check_usage Unhandled usage flags 0x8
fixme:d3d:resource_check_usage Unhandled usage flags 0x8
trace:file:CreateFileW L"C:\\Program Files\\CCP\\EVE\\lib\\carbonlib.ccp" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x8
trace:file:RtlDosPathNameToNtPathName_U (L"C:\\Program Files\\CCP\\EVE\\lib\\carbonlib.ccp",0x339e0c,(nil),(nil)
trace:file:RtlGetFullPathName_U (L"C:\\Program Files\\CCP\\EVE\\lib\\carbonlib.ccp" 520 0x339b50 (nil)
trace:file:wine_nt_to_unix_file_name L"\\??\\C:\\Program Files\\CCP\\EVE\\lib\\carbonlib.ccp" -> "/home/name/.wine/dosdevices/c:/Program Files/CCP/EVE/lib/carbonlib.ccp
trace:file:CreateFileW returning 0x8c
trace:file:ReadFile 0x8c8 0x2c1c5fb0 512 0x339eb0 (nil
trace:file:ReadFile 0x8c8 0x2c1c5fb0 512 0x339eac (nil
trace:file:ReadFile 0x8c8 0x2c1c61cc 3272 0x339f04 (nil
trace:file:RtlGetFullPathName_U (L"C:\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\//ships/" 520 0x33a8d8 (nil)
trace:file:GetFileAttributesExW L"C:\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\ships\\" 0 0x33a9d
trace:file:RtlDosPathNameToNtPathName_U (L"C:\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\ships\\",0x33a998,(nil),(nil)
trace:file:RtlGetFullPathName_U (L"C:\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\ships\\" 520 0x33a6e8 (nil)
trace:file:wine_nt_to_unix_file_name L"\\??\\C:\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\ships\\" -> "/home/name/.wine/dosdevices/c:/users/name/Local Settings/Application Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ships/
trace:file:RtlGetFullPathName_U (L"C:\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\//ships/29984_29972_30048_30088_30122_30143.black" 520 0x33a8d8 (nil)
trace:file:RtlGetFullPathName_U (L"C:\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\//ships/29984_29972_30048_30088_30122_30143.gr2" 520 0x33a8d8 (nil)
trace:file:RtlGetFullPathName_U (L"C:\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\//ships/29984_29972_30048_30088_30122_30143.lock" 520 0x33a8d8 (nil)
trace:file:GetFileAttributesExW L"C:\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\ships\\29984_29972_30048_30088_30122_30143.black" 0 0x33a9d
trace:file:RtlDosPathNameToNtPathName_U (L"C:\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\ships\\29984_29972_30048_30088_30122_30143.black",0x33a998,(nil),(nil)
trace:file:RtlGetFullPathName_U (L"C:\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\ships\\29984_29972_30048_30088_30122_30143.black" 520 0x33a6e8 (nil)
trace:file:wine_nt_to_unix_file_name L"\\users\\name\\Local Settings\\Application Data\\CCP\\EVE\\c_program_files_ccp_eve_tranquility\\cache\\ships\\29984_29972_30048_30088_30122_30143.black" not found in /home/name/.wine/dosdevices/c:/users/name/Local Settings/Application Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ship
fixme:msvcrt:MSVCRT__wsopen_s : pmode 0x01ff ignored

If you do that, be warned that flying a t3 is really weird. The camera can't do a "look at" on your own ship. So you can look at other stuff, but then can't reset the camera. Not the end of the world though.,

Okay, here it is, hilarious workaround time. This renders t3s invisible. And probably does evil stuff to your game.

Also, totally send me isk.

You'll need to locate your eve cache folder and adjust this from my settings.

Open a console, and input this:

while true; do rm -r ~/.wine/drive_c/users/murph/Local\ Settings/Application\ Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ships/*; done

This will start a continual loop that is deleting the generated ships cache (only t3s are generated, i think).

Now, in a second console, go start eve your usual way.

Okay, here it is, hilarious workaround time. This renders t3s invisible. And probably does evil stuff to your game.

Also, totally send me isk.

You'll need to locate your eve cache folder and adjust this from my settings.

Open a console, and input this:

while true; do rm -r ~/.wine/drive_c/users/murph/Local\ Settings/Application\ Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ships/*; done

This will start a continual loop that is deleting the generated ships cache (only t3s are generated, i think).

Now, in a second console, go start eve your usual way.

Make sure you've got the right directory for your cache. Some distros put it in other places or something.

"find ~ | grep /cache/ships" should point you in the right direction, might be slow tho.

err:winediag:shader_generate_glsl_declarations The hardware does not support enough uniform components to run this shader, it may not render correctly.

You could try doing winetricks glsl-disable and running without glsl.

Interestingly enough, I have no problems when using the tengu itself, but when I get on grid with another tech 3 cruiser or switch subsystems on the tengu, the crash is triggered.

Does anyone else have this?

It could be specific subsystem or subsystem combination which causes the crash.

I have the crash but no such line in output: http://pastebin.com/U3tEPeF9

Please don't spam the winehq people. Work on Wine is done on a volunteer basis - a bunch of people complaining just will irritate someone, not motivate them to be helpful. I'm a Wine developer (on unrelated parts).

But do post any additional logs, different systems/architectures/versions of whatever. That is useful information!

This seems to be an issue in how Python under Wine deals with file descriptors - opening a file with os.open and closing it with os.close causes this error.

The Python source code has a comment indicating that this is handled in a hacky way, using internal structures of the Microsoft CRT.

I'll see if I can achieve the same thing in a different way, but I don't have a way to test under Linux, nor should I technically be spending time on this, this being an unsupported platform and all. Still, I don't like seeing EVE crashing.

Hopefully this gives Wine developers a clue, nonetheless.

That line comes from the console output log, sorry i wasn't clear!

This seems to be an issue in how Python under Wine deals with file descriptors - opening a file with os.open and closing it with os.close causes this error.

The Python source code has a comment indicating that this is handled in a hacky way, using internal structures of the Microsoft CRT.

I'll see if I can achieve the same thing in a different way, but I don't have a way to test under Linux, nor should I technically be spending time on this, this being an unsupported platform and all. Still, I don't like seeing EVE crashing.

Hopefully this gives Wine developers a clue, nonetheless.

I'd be interested to know why it works fine on mac since I thought that was basically cedega/wine wrapped around eve anyway. Surely what works there would work here? (unless thats nastier hack I guess)

I believe they used to do this, however they implemented an OpenGL client for OSX a while back. Not sure why they can't implement the whole thing in OpenGL and then Linux support would be much better/easier to handle... but I respect that CCP Snorlax is giving it a shot even though it isn't supported. However, even with this small thread I think it's obvious that there are enough Linux users that are encumbered by this problem that it's worthwhile monetarily cor CCP to at least fix 1 or 2 problems we have with the client from time to time :)

o7 to CCP Snorlax!

and the CFC would miss us all as well haha

I'd be interested to know why it works fine on mac since I thought that was basically cedega/wine wrapped around eve anyway. Surely what works there would work here? (unless thats nastier hack I guess)

maybe the python thingie is working properly on mac. Could you take it from a mac over to a linux box somehow? I mean, mac os is based on linux, right?

The Python source code has a comment indicating that this is handled in a hacky way, using internal structures of the Microsoft CRT.

Gah. I remember getting in flamewars about using undocumented internal structures on the Commodore 64 two decades ago. I'd have thought better of the Python devs! I guess the temptation to "just make it work" using whatever hack seems to get the job done right now is just too much.

So I know only one way to reproduce this bug: using 2 EVE clients - one char alone in cheetah at pos (nobody in grid) and second character warping to that pos in tengu - constantly crashed first client at cheetah when I open from first char ship info of neighbor tengu and clicking with lens on ship model

I tried to reproduce error in python 2.7 installed under wine with file open code as described in http://bugs.winehq.org/show_bug.cgi?id=30515#c9 - but nothing happens, test string successfully written to file without error.

Can somebody, who understand why EVE crashes with modern ships models, tell me more details about reason why python 2.7 cannot do file operations under wine as good as under native win32 ?
I'll prefer to report bug or find patch for python or wine and rebuild them to solve this issue than moving back to dual-boot with windows to run only one application (eve).

Can somebody, who understand why EVE crashes with modern ships models, tell me more details about reason why python 2.7 cannot do file operations under wine as good as under native win32 ?

Okay, here it is, hilarious workaround time. This renders t3s invisible. And probably does evil stuff to your game.

Also, totally send me isk.

You'll need to locate your eve cache folder and adjust this from my settings.

Open a console, and input this:

while true; do rm -r ~/.wine/drive_c/users/murph/Local\ Settings/Application\ Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ships/*; done

This will start a continual loop that is deleting the generated ships cache (only t3s are generated, i think).

Now, in a second console, go start eve your usual way.

just to confirm that this makes the game playable. the only issue is when switching to a t3 while at a pos (did not test at a station).

# T3 bug fix for now
(while true; do rm -r ~/.wine/drive_c/users/gerard/Local\ Settings/Application\ Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ships/* 2>/dev/null; done) &
PID=$!

env WINEPREFIX="/home/gerard/.wine" taskset 1 wine explorer /desktop=EVE1,1920x1080 "C:\Program Files\CCP\EVE\eve.exe"

kill $PID

I have not tried anything further yet under Linux since it freezes my entire box when it crashes and I am at risk of trashing my harddrive or even damaging hardware. It never did this before the patch so now I have switched to Windows for running EVE.

Is anyone else getting hardware freezes?

Also, since it seems to be related to the client's cache could it possibly be solved by disabling the resource cache? It has this as an option in the settings...

# T3 bug fix for now
(while true; do rm -r ~/.wine/drive_c/users/gerard/Local\ Settings/Application\ Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ships/* 2>/dev/null; done) &
PID=$!

env WINEPREFIX="/home/gerard/.wine" taskset 1 wine explorer /desktop=EVE1,1920x1080 "C:\Program Files\CCP\EVE\eve.exe"

kill $PID

(
cd ~/.wine/drive_c/users/$USER/Local\ Settings/Application\ Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ships
while true
do
rm -f *lock >/dev/null 2>&1
done
) &

Try changing this loop to:

while true; do rm -r ~/.wine/drive_c/users/murph/Local\ Settings/Application\ Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ships/*.lock; done


That should allow you to see the generated t3 ships. The lock file that is generated is intended to prevent multiple EVE instances from thrashing - both wasting cpu cycles and potentially corrupting the files with simultaneous writes.

I'm trying to find alternatives of dealing with this - worst case I'll disable this if I detect we're running under Wine and you guys have to live with slightly worse performance when multiboxing.

Are you 100% sure it's hardware? Do you run windowed mode and can't alt-tab out? Have you tried moving to another console with Ctrl+Alt+F1 through F6 and killing the eve process?

Yes. I cannot CTRL-ALT-Left or -Right to switch through the virtual desktops nor CTRL-ALT-F1 - F6 to get to a console terminal nor does CTRL-ALT-DELETE work and neither does the mouse cursor move. All I can do is press the hardware reset on my case.

There is no sign of an kernel oops either, no dmesg or syslog entries. It freezes dead. Could be coincidence, but I already checked all cables, checked for dust and heat issues, but everything is ok. It then works flawlessly under Windows Vista. If I do not run WINE/EVE then Linux runs again stable, too. It makes searching for the cause a very unpleasant activity right now.

Yes. I cannot CTRL-ALT-Left or -Right to switch through the virtual desktops nor CTRL-ALT-F1 - F6 to get to a console terminal nor does CTRL-ALT-DELETE work and neither does the mouse cursor move. All I can do is press the hardware reset on my case.

There is no sign of an kernel oops either, no dmesg or syslog entries. It freezes dead. Could be coincidence, but I already checked all cables, checked for dust and heat issues, but everything is ok. It then works flawlessly under Windows Vista. If I do not run WINE/EVE then Linux runs again stable, too. It makes searching for the cause a very unpleasant activity right now.

Try changing this loop to:

while true; do rm -r ~/.wine/drive_c/users/murph/Local\ Settings/Application\ Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ships/*.lock; done


That should allow you to see the generated t3 ships. The lock file that is generated is intended to prevent multiple EVE instances from thrashing - both wasting cpu cycles and potentially corrupting the files with simultaneous writes.

I'm trying to find alternatives of dealing with this - worst case I'll disable this if I detect we're running under Wine and you guys have to live with slightly worse performance when multiboxing.

(cd ~/.wine/drive_c/users/Your_Username/Local\ Settings/Application\Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ships
while true; do
rm -f *.black;
done)&
PID=$!

env WINEARCH=win32 WINEPREFIX=Path_To_Wineprefix wine explorer /desktop=EVE,1920x1080 Path_To_EXE/drive_c/Program\ Files/CCP/EVE/eve.exe

kill $PID

fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
fixme:dbghelp:elf_search_auxv can't find symbol in module
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do!
wine: Unhandled page fault on read access to 0x30ce0da8 at address 0x4e9354f (thread 002f), starting debugger..
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:04e9354f ESP:0033a828 EBP:0033a860 EFLAGS:00010202( R- -- I - - - )
EAX:30ce0d90 EBX:093a97a8 ECX:cb5104cd EDX:04c620a0
ESI:2da243a0 EDI:02ad42a8
Stack dump:
0x0033a828: 00000044 093c5d78 2e2634a4 00000120
0x0033a838: 30516ba0 2da243a0 30ce0d90 00000000
0x0033a848: 0033a934 04ea0083 00000120 0033a928
0x0033a858: 050c0448 ffffffff 0033a934 04ea01e5
0x0033a868: 093a97a8 2f70d00c 0947a81c 093c97c8
0x0033a878: 02d56d10 00000000 3f800000 3f800000
Backtrace:
=>0 0x04e9354f in _trinity_deploy (+0x70354f) (0x0033a860)
1 0x04ea01e5 in _trinity_deploy (+0x7101e4) (0x0033a934)
2 0x04851850 in _trinity_deploy (+0xc184f) (0x0033a954)
3 0x04eb3020 in _trinity_deploy (+0x72301f) (0x0033a9c0)
4 0x04eb2aaf in _trinity_deploy (+0x722aae) (0x0033a9ec)
5 0x04eb3020 in _trinity_deploy (+0x72301f) (0x0033aa58)
6 0x04eb2aaf in _trinity_deploy (+0x722aae) (0x0033aa84)
7 0x04ecd78b in _trinity_deploy (+0x73d78a) (0x0033ab28)
8 0x04d4c015 in _trinity_deploy (+0x5bc014) (0x0033ab34)
9 0x04d19fb6 in _trinity_deploy (+0x589fb5) (0x0033ab88)
10 0x04a29a55 in _trinity_deploy (+0x299a54) (0x0033ac64)
11 0x04a328d3 in _trinity_deploy (+0x2a28d2) (0x0033ad1c)
12 0x04a367e7 in _trinity_deploy (+0x2a67e6) (0x0033ad60)
13 0x04a25fe1 in _trinity_deploy (+0x295fe0) (0x0033adc0)
14 0x1003e448 in blue (+0x3e447) (0x0033af04)
15 0x1003f521 in blue (+0x3f520) (0x0033b014)
16 0x100484e9 in blue (+0x484e8) (0x0033b024)
17 0x1e01d246 in python27 (+0x1d245) (0x018ef770)
0x04e9354f: movl0x18(%eax),%ecx
Modules:
ModuleAddressDebug infoName (167 modules)
PE 3d0000- 3f8000Deferred tbb
PE 400000- 48b000Deferred exefile
PE 2130000- 21e9000Deferred _ssl.pyd
PE 2370000- 23a6000Deferred _yaml.pyd
PE 23b0000- 247e000Deferred umbra
PE 2480000- 2577000Deferred apexframework_x86
PE 4790000- 5537000Export _trinity_deploy
PE 5540000- 5725000Deferred d3dx9_42
PE 5730000- 5743000Deferred physxloader
PE 5da0000- 5dbb000Deferred geo2
...

Yeah, if you're on jita undock, forget playing eve forever on Linux. Script doesn't work at all in those scenerios either.

Which is too bad, I wanted to watch the firework display planned.

The apparent hang is probably due to you running wine in full screen and with software cursor (for some reason), and there is a setting that can trap your mouse within the active window. In these situations, it's best to run wine with a virtual desktop. For me, I have something like this:.

The problem is that he/she can't even Ctrl+Alt+F1 to get to a new virtual console. This rules out the error you described.

Ive had it before when X has locked up in such a way that Ctrl+Alt+F1 wouldn't work for me either. Either the keys were being intercepted or the screen was overlayed with nothing and the console was working underneath (although the command to restart X didn't work).

I've had it were only ssh'ing in would allow me to kill X and go from there. When wine dies it can be nasty :)

Jesus, that's awful. I guess I'm lucky I've never had that. I didn't even think that was possible for something like this.

We should have a potential fix out on Sisi tomorrow afternoon. Fingers crossed...

We should have a potential fix out on Sisi tomorrow afternoon. Fingers crossed...

With CCP now fixing this issue (BIG thanks for that, CCP Snorlax!) I'm not sure wether I should post my somewhat very ugly temporary solution. It involves patching and recompiling wine from source and might break other windows apps (and possibly more).

But I was able to sit a Jita IV Station for at least 2 hours without a single crash. It might not work for you though. I didn't get feedback from the people in "Linux" so far.

http://pastebin.com/iMN6FT86

Nevertheless it would be much better if the problem gets fixed either by CCP or the wine devs.

Edit: The patch above was created against wine 1.4 but also might apply against newer versions.

#!/bin/bash

cd "/home/YOUR-USER/.wine/drive_c/users/YOUR-USER/Local Settings/Application Data/CCP/EVE/c_program_files_eveonline_tranquility/cache/ships"

inotifywait -m -e close_write --format '%f' . | while read file
do
if [ "${file#*.}" = "black" ] ; then
rm $file
fi
done

We should have a potential fix out on Sisi tomorrow afternoon. Fingers crossed...

With CCP now fixing this issue (BIG thanks for that, CCP Snorlax!) I'm not sure wether I should post my somewhat very ugly temporary solution. It involves patching and recompiling wine from source and might break other windows apps (and possibly more).

But I was able to sit a Jita IV Station for at least 2 hours without a single crash. It might not work for you though. I didn't get feedback from the people in "Linux" so far.

http://pastebin.com/iMN6FT86

Nevertheless it would be much better if the problem gets fixed either by CCP or the wine devs.

Edit: The patch above was created against wine 1.4 but also might apply against newer versions.

My attempt at a fix is now on Sisi - please give it a go and report back.

My attempt at a fix is now on Sisi - please give it a go and report back.

Just checked on SiSi, no more crashes on tengu preview. Thank you!

Does it fix crashes in space ?

how can I get to SiSi ???
http://wiki.eveonline.com/en/wiki/Sisi_Launcher - is deprecated, what shall I do ?

My attempt at a fix is now on Sisi - please give it a go and report back.

I believe the next scheduled client update is on Monday and this fix will be included in that.

#!/bin/bash
IFS="
"
eveFolder="/home/glemsom/.wine/drive_c/users/glemsom/Local Settings/Application Data/CCP/EVE/c_program_files_(x86)_ccp_eve_tranquility/cache/ships"

rm -f "$eveFolder"/*

inotifywait --format %f -e create -m "$eveFolder" | while read file
do
rm -f "$eveFolder"/"$file"
done

I works if I remove all the quotes around file pathes and variable names... so no iskies :p But big thanks, because I couldn't get the previous inotify version to work :)

With CCP now fixing this issue (BIG thanks for that, CCP Snorlax!) I'm not sure wether I should post my somewhat very ugly temporary solution. It involves patching and recompiling wine from source and might break other windows apps (and possibly more).

But I was able to sit a Jita IV Station for at least 2 hours without a single crash. It might not work for you though. I didn't get feedback from the people in "Linux" so far.

http://pastebin.com/iMN6FT86

Nevertheless it would be much better if the problem gets fixed either by CCP or the wine devs.

Edit: The patch above was created against wine 1.4 but also might apply against newer versions.

With CCP now fixing this issue (BIG thanks for that, CCP Snorlax!) I'm not sure wether I should post my somewhat very ugly temporary solution. It involves patching and recompiling wine from source and might break other windows apps (and possibly more).

But I was able to sit a Jita IV Station for at least 2 hours without a single crash. It might not work for you though. I didn't get feedback from the people in "Linux" so far.

http://pastebin.com/iMN6FT86

Nevertheless it would be much better if the problem gets fixed either by CCP or the wine devs.

Edit: The patch above was created against wine 1.4 but also might apply against newer versions.

...not sure if it is the right guide though.

But I was able to sit a Jita IV Station for at least 2 hours without a single crash. It might not work for you though. I didn't get feedback from the people in "Linux" so far.

http://pastebin.com/iMN6FT86

Nevertheless it would be much better if the problem gets fixed either by CCP or the wine devs.

Edit: The patch above was created against wine 1.4 but also might apply against newer versions.

Seems there was a client patch today. I can fly my T3 in Tranquillity today! Yay CCP! And thanks for the help Snorlax! You rock!

I believe the next scheduled client update is on Monday and this fix will be included in that.

Awesome! Looking forward to it.


Aside: my workaround that seems to work is just symlink of ships directory in cache to /dev/null.

Awesome! Looking forward to it.


Aside: my workaround that seems to work is just symlink of ships directory in cache to /dev/null.

I believe the next scheduled client update is on Monday and this fix will be included in that.

My attempt at a fix is now on Sisi - please give it a go and report back.

With CCP now fixing this issue (BIG thanks for that, CCP Snorlax!) I'm not sure wether I should post my somewhat very ugly temporary solution. It involves patching and recompiling wine from source and might break other windows apps (and possibly more).

But I was able to sit a Jita IV Station for at least 2 hours without a single crash. It might not work for you though. I didn't get feedback from the people in "Linux" so far.

http://pastebin.com/iMN6FT86

Nevertheless it would be much better if the problem gets fixed either by CCP or the wine devs.

Edit: The patch above was created against wine 1.4 but also might apply against newer versions.

Confirming that it works for me as well. Kudos to CCP Snorlax for sorting out this issue so fast. Many thanks!

Thank you for this fix (I'm not using Ubuntu right now, I just appreciate support for it), even though whoever wrote the patch notes went passive-aggressive with their rude mention of the fix.

Snorlax, you're a superhero. Hugely appreciated.

no more crashes, I can finaly play.

however I noticed a GFX glitch, the engine trail (exhaust fumes for a lack of better word) now have clipping problems. I can see their origin points through the other side of my ishkur.

anybody has the same ?

it's not a big deal, just noticed it today.

no more crashes, I can finaly play.

however I noticed a GFX glitch, the engine trail (exhaust fumes for a lack of better word) now have clipping problems. I can see their origin points through the other side of my ishkur.

anybody has the same ?

it's not a big deal, just noticed it today.

https://forums.eveonline.com/default.aspx?g=posts&t=103128

That's completely unrelated, that glitch has been there for pretty much forever.

Some how we became a bunch of whiners wasting CCP's time.

I believe the next scheduled client update is on Monday and this fix will be included in that.

never happened to me before ... I see it first time in about 2 years ....

That's completely unrelated, that glitch has been there for pretty much forever.

I am still seeing hard freezes when EVE runs under WINE/Linux with today's update. Without it does it run stable and is also running stable under Windows Vista.

Hardware is AMD Phenom 9850 (quad-core, 2.5GHz), Nvidia GeForce GTX260, Linux kernel 3.2.12, 295.40 Nvidia driver. No heat issues, no over-clocking, all cables checked, power draw well below maximum. Best guess I have is it is a software lock-up in the kernel/gfx driver.

Try disabling shadows / bloom / postprocessing, i clearly remember one of these things causes such issue to appear.

That Aphoxema guy has serious problems.

Probably CCP Snorlax (praise be unto him!) just swapped "os.open(...)" for "open(...)" or something equally trivial in dealing with T3 cache files, posted a total of three messages (one of which clearly after icelandic work hours), became an instant hero in our sub-community, but also apparently wasted time and money in order to help a whiny minority.

I think I can roll my eyes till they literally fall on the floor...

never happened to me before ... I see it first time in about 2 years ....

Try disabling anti-aliasing, fixed it for me.

By my rough guestimate 600-700 linux account players easily pay for a developers salary if that developer's entire purpose was to test and support linux.

With CCP now fixing this issue (BIG thanks for that, CCP Snorlax!) I'm not sure wether I should post my somewhat very ugly temporary solution. It involves patching and recompiling wine from source and might break other windows apps (and possibly more).

But I was able to sit a Jita IV Station for at least 2 hours without a single crash. It might not work for you though. I didn't get feedback from the people in "Linux" so far.

http://pastebin.com/iMN6FT86

Nevertheless it would be much better if the problem gets fixed either by CCP or the wine devs.

Edit: The patch above was created against wine 1.4 but also might apply against newer versions.

using this patch on wine 1.5.2 - patching EVE is correctly without changing build,native on the wine