These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Linux

 
  • Topic is locked indefinitely.
 

Client crashes on Ubuntu 11.10

First post
Author
Previous Topic Next Topic
Sidra Necia
Imperial Academy
Amarr Empire
#101 - 2012-04-26 13:45:41 UTC  |  Edited by: Sidra Necia
CCP Snorlax wrote:
Nebu Retski wrote:
NegatedVoid wrote:
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).

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.

Removing the .lock files doesn't work for me either.

Only the removing the files with extension .black works.
On the plus side the rest of the files are some other caches which we get to keep using as intended ;)

So the script becomes:
Quote:

(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

I have no idea what the .black files are, but removing them disables T3 previewing ...etc (I don't own a T3)

Regarding wine detection: (in case the issue can not be fixed)
How about simply adding either a menu entry in settings named "Linux overrides" or put it in some config file ?
So if this option is ticked off or included client falls back to whatever code you had before the patch (regarding the .black issue). Or alternatively to whatever fixes are needed.

And yes I don't mind you counting how many ppl use Linux :)
It might turn out that there is plenty of us \o/ so just another fun statistic...

Edit :
The sad thing is that now this script eats more cpu than the eve client :(
Spec:
i5 2500k
gtx 570
8g ram

Client crashed again :( This time in space, no idea what happened. I was about to dock up.
Have to test weather removing all cache files fixes it...
Output:
Quote:
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: movl 0x18(%eax),%ecx
Modules:
Module Address Debug info Name (167 modules)
PE 3d0000- 3f8000 Deferred tbb
PE 400000- 48b000 Deferred exefile
PE 2130000- 21e9000 Deferred _ssl.pyd
PE 2370000- 23a6000 Deferred _yaml.pyd
PE 23b0000- 247e000 Deferred umbra
PE 2480000- 2577000 Deferred apexframework_x86
PE 4790000- 5537000 Export _trinity_deploy
PE 5540000- 5725000 Deferred d3dx9_42
PE 5730000- 5743000 Deferred physxloader
PE 5da0000- 5dbb000 Deferred geo2
...
CCP Snorlax
C C P
C C P Alliance
#102 - 2012-04-26 15:05:07 UTC
We should have a potential fix out on Sisi tomorrow afternoon. Fingers crossed...

CCP Snorlax - Software Architect - Team RnB - @CCP_Snorlax - http://ccpsnorlax.blogspot.is/
Kismeteer
Bat Country
Pandemic Horde
#103 - 2012-04-26 15:06:53 UTC  |  Edited by: Kismeteer
e: ^^^ Nice job man. It's good to see a dev posting in here again too.

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.
Spoofeydoo
Eternity INC.
Goonswarm Federation
#104 - 2012-04-26 15:10:57 UTC
Kismeteer wrote:
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.


It took me a couple hours to get out of Jita when I made that mistake.

I have a fruit cup and I'm not afraid to use it.
Lairel Dallocort
Hot Lobster
#105 - 2012-04-26 15:14:41 UTC
DJ Rubbie wrote:
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.
Maquis196
Red vs Blue Flight Academy
#106 - 2012-04-26 15:25:15 UTC
Lairel Dallocort wrote:
DJ Rubbie wrote:
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 :)
Lairel Dallocort
Hot Lobster
#107 - 2012-04-26 15:31:34 UTC
Maquis196 wrote:
Lairel Dallocort wrote:
DJ Rubbie wrote:
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.
Maquis196
Red vs Blue Flight Academy
#108 - 2012-04-26 16:00:02 UTC
Lairel Dallocort wrote:
Maquis196 wrote:
Lairel Dallocort wrote:
DJ Rubbie wrote:
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.


Well you have a binary blob driver and if thats involved in a crash then it could cause some nasty things to happen. At least the box technically didn't crash, just the UI (even the cli). As long as you can ssh in you're fine. When windows locks up we all know what happens there...
Dwindlehop
Imperial Shipment
Amarr Empire
#109 - 2012-04-26 16:44:34 UTC
Everyone needs to Like CCP Snorlax's posts!
https://forums.eveonline.com/default.aspx?g=posts&m=1196841#post1196841
Thanks so much for spending your time on this!

Does anyone else using the cache-clearing workaround find they can't see into cargo holds any more? T3 models I can live without, but the contents of cargo are a little more important. A Sisi fix is great news.
Darkpepper
Flying like a Rock
#110 - 2012-04-26 17:15:50 UTC
CCP Snorlax wrote:
We should have a potential fix out on Sisi tomorrow afternoon. Fingers crossed...


"like" clicked :P

Btw the number of players under linux could be a precious information for the futur . Steam recently announce an upcoming linux support... Smile

And thank you for your support Snorlax, i'll cross my fingers for tomorrow tests! Blink

**W**ormhole space, **L**inux Mint, **F**ree cookies
Zinh gardar
Doomheim
#111 - 2012-04-26 18:44:10 UTC
wow not a lot of games have dev team and or dev that will help out with a unsupported OS!!!!!!!!!!!!! im new to the game and all i have to say is wtg customer care!
kakmonstret
Domain Mining and Trading Corp
#112 - 2012-04-26 19:08:43 UTC
CCP Snorlax wrote:
We should have a potential fix out on Sisi tomorrow afternoon. Fingers crossed...


Fantastic!

I think your nonsupport kick some other developers support ass. Lol
MourningWood
Federal Navy Academy
Gallente Federation
#113 - 2012-04-26 19:45:58 UTC
I would just like to reiterate how cool it is for a dev to look into this for us. I do all my work under Linux a lot of times while playing EVE. Its been a real pain to reboot into Windows whenever I feel like playing and not being able to get work done at the same time.
Ny Draconis
Black Hat Inc.
#114 - 2012-04-26 19:49:34 UTC  |  Edited by: Ny Draconis
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.
Maquis196
Red vs Blue Flight Academy
#115 - 2012-04-26 19:52:50 UTC
Ny Draconis wrote:
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.


For this people should consider doing it the way I do; for any wine with custom patches do;

./configure --prefix=/usr/local/wine-1.5.2-Evefix

then you can play eve with the custom wine by;

/usr/local/wine-1.5.2-Evefix/bin/wine eve.exe

This will keep your system wine seperate, I must have about 20 wines in my /usr/local for all manor of games. Then when wine/eve is fixed, just delete it :) all nicely in the same place.
Nurias
Doomheim
#116 - 2012-04-26 20:15:14 UTC
Only for the sake of demonstrating that we are many ;) I am just another linux user who eagerly awaits the upcoming fix for the fd/python problem we are suffering from. Thanks for the help ccp snorlax!

Best regards
Nurias
Merende Macaco
Tranquility Tavern
Pandemic Horde
#117 - 2012-04-26 21:50:38 UTC  |  Edited by: Merende Macaco
Quote:
Edit: The patch above was created against wine 1.4 but also might apply against newer versions.


I manually edited the files in question in my wine 1.5.2 build dir, but the lines in question were in the same location.
I am busy re - make'ing
will edit this post once the build/install is done and I test (will try just opening the SHIP preview in station - don't really want to undock my carrier into a potentially hostile situation Shocked)


test seems to be successful, I have previewed various T3 ships with no ill effect
Capitain Blood
Sajuuk-Khar Corporation
#118 - 2012-04-26 22:51:43 UTC

I wrote a snippet of script to remove black files in cache if you need it:

You need to have sys-fs/inotify-tools installed and inotify support in your kernel.
That remove .black file at each close_write file event.


Quote:
#!/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
Chocratess
The Great Bleu Galoo
#119 - 2012-04-27 01:23:10 UTC
Just to jump on this band wagon, i too am crashing in space now.

Thank you CCP for even looking at a linux OS!
velusip
Perkone
Caldari State
#120 - 2012-04-27 02:44:36 UTC
running the cache clearing hack, game runs better than ever without those unsightly Tengu's around... however I do miss the Loki's.