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
kakmonstret
Domain Mining and Trading Corp
#81 - 2012-04-25 13:31:06 UTC
Xin Chang wrote:
CCP Snorlax wrote:
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.


Without knowing I would guess this to work around some limitation in the CRT. According to comments to the wine bug it's in the function _PyVerify_fd which may require theses sort of hacks. So this could been the case of choosing between one ugly hack or another ugly hack (e.g. always returning that the fd is okay), Sadly the real world isn't always as nice as you would want.
kakmonstret
Domain Mining and Trading Corp
#82 - 2012-04-25 13:52:00 UTC
Ouch seems like this is non trivial to fix in wine. =(

This is the bug that the eve report been said to duplicate:

http://bugs.winehq.org/show_bug.cgi?id=29764
Xin Chang
Garoun Investment Bank
Gallente Federation
#83 - 2012-04-25 14:26:51 UTC
Katrina Bekers wrote:
Side note: WTF guys! All of CFC uses linux or what? /dev/VFK by February!


In any event, this new bug may give you a new way to mine safely during Hulkageddon. Just have a Tengu sitting at the belt.
Marsan
#84 - 2012-04-25 15:44:20 UTC
A thought maybe it might be worth while to see if we can get msvcr*(native, builtin) working again.

Former forum cheerleader CCP, now just a grumpy small portion of the community.
Fam Trinly
Russian SOBR
#85 - 2012-04-25 16:20:03 UTC  |  Edited by: Fam Trinly
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).
Leo Musana
The Wowbaggers
#86 - 2012-04-25 16:21:49 UTC
I'm also one of the affected :(
Could EVE dev plz inplement a quick disable option for the ship cash or even drawing of the T3 ships affected.
So the game is atleast playable untill a more permanent fix can be found?
Buzzy Warstl
Quantum Flux Foundry
#87 - 2012-04-25 16:27:57 UTC
Fam Trinly wrote:
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).

I was able to trigger it in station using the preview function from "show info".

http://www.mud.co.uk/richard/hcds.htm Richard Bartle: Players who suit MUDs
NegatedVoid
Native Freshfood
Minmatar Republic
#88 - 2012-04-25 16:59:37 UTC
Fam Trinly wrote:

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 ?


Sure. When you open a file, you get a "file descriptor" that is like a pointer to it. When you're done, you're supposed to close it.

The python developers have "os.open" and "os.close" for this - they pass through to the underlying operating system's open and close calls.

If you attempt to close an invalid file descriptor (like .. one that's not open already), the C runtime (msvcrt in this case) will throw an error. However, the Python developers want to have a python exception instead so they do error checking themselves. In order to see if the the file descriptor is "open" already, they have to poke around the internal memory of MSVCRT.

Wine reimplements the Windows API's, such as MSVCRT. So when the python code goes poking inside the memory of the runtime, it's actually poking inside of the memory of the Wine version.

Unfortunately, there is a host of these runtimes (MSVCR80, MSVCR90, MSVCR100, etcetc) that have mostly similar methods with some difference (for example, the structure that holds the needed information is different on each). In Wine, they're all mostly implemented once, not for each version.

So in order to use the expected memory layout, I think that Wine would have to create separate implementations for each of these runtimes, which is a lot of work and leads to a lot of code duplication which is bad.

I'm still working on figuring out the details of how Wine is handling this, but my initial attempts at simple fixes have been unsuccessful. If you're *reallly qualified* please contact me to help, but if you're just casually qualified it might not do much good.
Nebu Retski
Lead Farmers
#89 - 2012-04-25 20:08:34 UTC
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).
CCP Snorlax
C C P
C C P Alliance
#90 - 2012-04-25 21:30:44 UTC
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.

CCP Snorlax - Software Architect - Team RnB - @CCP_Snorlax - http://ccpsnorlax.blogspot.is/
Zaknapan
Sebiestor Tribe
Minmatar Republic
#91 - 2012-04-25 21:35:59 UTC  |  Edited by: Zaknapan
I am affected too... the loop works for me, but sometimes it still crashes. Always with a t3 on grid, so that much seems reproducible at least.

I tried setting the ship cache to read-only but that just freezes the game, until you set it writeable and then it crashes :-(

My start script for eve does now look something like:


Quote:
# 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


This way you dont need to start it seperately and you wont forget to kill it either when done... Still a ugly hack and I would rather see it go.

PS: Thanks Snorlax for looking into this. I think many of us already gave up hoping that 'real' Linux support will ever come available, but it is nice to see that at least some of this is getting through and someone seems to care!
TWHC Assistant
#92 - 2012-04-25 21:40:58 UTC
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...
Lairel Dallocort
Hot Lobster
#93 - 2012-04-25 22:48:56 UTC
TWHC Assistant wrote:
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...

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?
Lairel Dallocort
Hot Lobster
#94 - 2012-04-25 22:49:54 UTC
Quote:
# 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


This is excellent. I have no command-line-fu so this helps a bunch!
Katrina Bekers
A Blessed Bean
Pandemic Horde
#95 - 2012-04-25 23:35:45 UTC
A performance hint:

Since the while-do-done cycle goes on endlesslly, and repeats as fast as possible, you're better off with the "cd" OUTSIDE the cycle, so the filesystem has to traverse the inodes only once, and not at every cycle:
Quote:

(
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
) &

Also, CCP Snorlax, be careful with "WINE detection".

First and foremost, because there's no easy way to be sure you're actually in a WINE environment - peeking at registry keys is deprecated by WINE devs.

Second, because once you walk down that path, expect to be asked to "count us" by the rabid grues that dwell in this forum. Really, that'd be a serious matter for us linux players. <3

<< THE RABBLE BRIGADE >>
NegatedVoid
Native Freshfood
Minmatar Republic
#96 - 2012-04-25 23:55:23 UTC
Hah, thanks for the update to my terrible script.

I think that checking kernel32 for the "wine_get_unix_file_name()" function is better than using registry. But yeah it's a hack.

Better than a wine-detecting hack would be a command line argument or a settings file. Then there's no trickery - just set an option somewhere.

I've got a serious research deadline on the 3rd, but I'm willing to try my hand at reimplementing the msvcrt stuff after that. So maybe we could get a hack in for a while until I (or someone!) can get things working in Wine?
Palovana
Inner Fire Inc.
#97 - 2012-04-26 02:15:01 UTC
CCP Snorlax wrote:
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.


Just rm'ing the lock files didn't work for me - I still got the crashes.

So I'm rm'ing the *.lock, *.black, and *.gr2 files which is a little "cleaner" than just "rm *" in case I run it in a wrong dir.

Please support: export of settings in editable format

Your stuff goes here.
TWHC Assistant
#98 - 2012-04-26 07:31:58 UTC
Lairel Dallocort wrote:
TWHC Assistant wrote:
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...

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.
Maquis196
Red vs Blue Flight Academy
#99 - 2012-04-26 08:41:47 UTC
TWHC Assistant wrote:
Lairel Dallocort wrote:
TWHC Assistant wrote:
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...

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.


I find in situations like this, the only real way into a box is through ssh. If that's down then you can honestly say the box is a gonner. Of course you need another machine nearby for this (or smartphone). Saves time rebooting :)
DJ Rubbie
W-Space IT Department
Test Alliance Please Ignore
#100 - 2012-04-26 11:02:20 UTC
TWHC Assistant wrote:
Lairel Dallocort wrote:
TWHC Assistant wrote:
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...

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.


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:

$ WINEPREFIX=~/.wine-eve wine explorer /desktop=name1,1920x1080 bin/ExeFile.exe

WINEPREFIX is where I have a custom wine profile for eve (because somewhere my original profile got hosed and winetricks fails to install anything and I have things that still work with it)

explorer runs explorer, with the /desktop=name1 switch - this spawns a virtual desktop with the name `name1`. Replace name1 with something else to uniquely identify virtual desktops so to make it possible to run multiple instances of EVE under different virtual desktops. Virtual desktops are basically a window dedicated to a set of programs under the same desktop name - in this case a single instance of EVE.

1920x1080 is my desktop resolution, and by default if the specified resolution matches your screen resolution, the window will become a full screen window so it looks like you have a fullscreen app. Any lower resolution will look like running EVE in a windowed mode. Naturally replace this with your screen resolution. Just make sure your in-game resolution settings match this though.

bin/ExeFile.exe points the actual eve client. Not the launcher, because the launcher will crash for me if I try to start the game with it (causes the Visual C++ runtime errors).

Now, this being a virtual desktop, your normal window manager hotkeys should work, and if you alt-tab you should be able to tab back to your desktop or console and kill this offending task with:

$ WINEPREFIX=~/.wine-eve wineserver -k

Hopefully this should at least alleviate your crash issue.

---

That said, thanks for your horrible script - I can get the game not to crash with the complete removal of all files, but just removing the .lock files does not work, probably because I run EVE with a SSD thus read operations might have been faster than the removal. Anyway, thanks to CCP Snorlax for looking into this.