[SOLVED] Random crash on undock/jump

EDIT: Solved - this was an issue with glibc where calling sin() with very specific values caused it to segfault. Since wine was not compiled with debugging information it did not reveal the full backtrace which goes into libm.so. Upgrading glibc to the latest release candidate version solves this

Mods: feel free to delete this.

Alright, I gathered as much as I can about this issue so here it is:

When using Wine/DXVK (see Edit above) with EVE, it works perfectly (and at great performance), apart from a single annoying issue:
Sometimes (~30%-ish chance) when undocking/jumping through a gate the game randomly crashes with the following backtrace:

Backtrace:
=>0 0x7eefdd30 (0x00339828)
1 0x7e6037aa (0x00339878)
2 0x7e602b19 (0x003398d0)
3 0x03de8f29 in _trinity_dx11_deploy (+0x828f28) (0x447d775c)
0x7eefdd30: fldl 0x0(%edx,%eax,8)

I’ve noticed that this seems to happen only when the game is loading new in-game structures like stations, so whenever it is loading geometry.

The fldl instruction seems to be doing fld [edx+eax*8]

I believe this could be some sort of race condition. I tried winedbg but it’s very limited, so I didn’t get too far. The full backtrace can be found here.

Note: It does not matter if EVE is run from the launcher’s wineenv or if using a separate brand new and up-to-date (3.16) Wine prefix. Happens either way. The driver also does not matter, I tried both with integrated and dedicated card.

So far, I have tried pinning EVE to a single core, and other various random ideas, to no avail.

System info:
Gentoo Linux 64bit - 4.19.0-rc3

  • Intel i7-4500U
  • AMD Radeon HD 8850M
  • Latest (from git master) llvm, clang, mesa, vulkan drivers
  • Wine 3.16
  • DXVK 0.72 [confirmed not the issue]

Edit: Similar issue someone experienced on a Mac - https://forums-archive.eveonline.com/topic/516069/
Edit: And another one, more recent, also on Mac - MAC Crashing

Edit edit: Check post #15, it seems to be connected to the StructureDeployment service.

Do you have any more specifics? Because I get no crashes with DXVK. However, I’m using an Nvidia card with their proprietary driver. Also my WINE is only their current development version and not WINE staging or any other version of it.

I don’t know what else to specify honestly, I am using vanilla Wine 3.15 (atm compiling the latest 3.16). I tried compiling DXVK myself but that didn’t fix the issue.

Someone in the in-game Linux channel also said DXVK works for them perfectly and they were too using the nvidia driver.

I don’t think this is an AMD specific issue as it happens with my integrated Intel card as well.
(Maybe some common issue with the open source stack? We won’t find out without knowing what that instruction does. If it’s for example loading data from some geometry shader then it might be a bug in let’s say llvm/clang/mesa where it would be returning some different data type/value.)

So far the record has been 5 gate jumps without crash. I think I might have narrowed it down to when it’s loading stations or other nearby geometry. Disabling the Resource Cache has no effect. I also tried lowering all settings to their minimums and that didn’t change anything either.

Is this the same PC?

Yes, the intel being the integrated card, and AMD being the dedicated one.

Could it be memory, PSU or cooling related? Did you check for it?

Seeing how two different GPUs trigger the same issue could this be a problem with a completely different component, which only starts showing due to the higher performance you’re now getting from DXVK.

If you can exclude any hardware stability issues then you should look into MESA issues and give the stable branches a try.

I am certain this is not a hardware issue. EVEs graphics engine crashes in the same place every time and it happens only when undocking/finishing a gate jump. No way the system is gonna fail exactly in those moments.

EVE is not the only game I play, nor is it the highest demanding one. So I am certain my system can take the tiny load that running Eve is. Hell, compiling Wine is a gigantic load compared to running EVE, especially when I compile on all my cores.

Edit: Just tested with Wine 3.16 in a fresh wine prefix, same issue.

You could try installing a vanilla Ubuntu or Debian and see if it reproduces there. If this was a common problem the we’d all be having it and we’d see several reports about it by now.

And since you state that you’re using mostly the latest sources could you possibly have picked up a bug. Only way to find out is to roll back to something more tested and stable.

Update: Found a similar issue on the following thread, https://forums-archive.eveonline.com/topic/516069/
Seems to have happened on mac as well. So this is more likely an issue with Wine/EVE itself and not DXVK.
Edit: Confirmed not an issue with DXVK, happens without it as well. I updated the main post to reflect this.

Did you try to clear the resource cache or to disable it entirely?

I have tried both. I also tried downloading everything before launching Eve so it does not have to download new data on the fly.

It also occurs with a complete fresh EVE installation?

I wish I could give you more than just questions. I jump through a lot of systems each day, including Jita. Lots of docking and undocking, all without a single crash. I’ve tried using the dynamic camera and also with it turned off. I’ve tried it with the orbit camera and the 1st person view. It simply runs without any issues.

If I’m being very pedantic then I can make out slight micro stutters under Linux whereas Windows renders the 3D scene perfectly smooth. Windows shows better AA contours than Linux does. The later still has a few jagged edges within some of the objects while other contours get properly anti-aliased. Those are however very minor differences in detail and only noticeable on the pixel level. Only when one has played EVE on Windows for a while and switches back to Linux can one notice it. This is entirely cosmetic and doesn’t affect the game play at all. The visual artifacts by DX9/OpenGL are more visible than this in comparison. Like I said, this is me being very pedantic. My guess is it has to do with the differences in the Nvidia drivers for Linux and Windows, with the Windows driver offering far more options to control the output.

There are however no crashes of any kind on my end. Even a visual glitch, which can be seen under Windows occurs exactly the same on Linux… When one is on the 1st person camera and jumps through a gate then the “jump tunnel” animation smears off to one side whereas in the orbit camera does it render correctly and the “jump tunnel” simply fades away and holds it’s direction. This was once a bug before we had the first person view and it got fixed pretty soon after it occurred. This bug is however still present with the 1st person view, and it is visible in Linux and Windows.

Yes, so far I have tested 4 different Wine prefixes all with a fresh install of EVE.

It is indeed a very weird issue, I however guess it is at least a bit reassuring knowing that it also happens on Mac with different hardware configurations, the common denominator being Wine.
Another thing that just occurred to me is that Macs usually also have Radeon cards, so the issue could be there. Still won’t explain why it happens on Intel integrated tho.

I guess for now I’ll just live with it, and maybe try to debug the trinity dll in my free time to try and guess what the function is for where the crash occurs.

Update: LogLite show’s the following warning right before the crash:

(I manually reformatted since it printed the stacktrace as a list)

Attempting to use position of a released ball, returning (0, 0, 0)
File "C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\packages\bluepy\init.py line 36, in CallWrapper
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\parklife\gameui.py”, line 1129, in _DoBallClear
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\ui\view\spaceToSpaceTransition.py”, line 114, in Finalize
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\environment\effects\Jump.py”, line 214, in Stop
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\ui\view\spaceView.py”, line 152, in ActivatePrimaryCamera
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\parklife\sceneManager.py”, line 347, in SetPrimaryCamera
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\parklife\sceneManager.py”, line 306, in _ApplyCamera
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\ui\camera\tacticalCamera.py”, line 166, in OnActivated
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\ui\camera\baseSpaceCamera.py”, line 242, in OnActivated
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\ui\camera\baseCamera.py”, line 147, in OnActivated
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\ui\camera\tacticalCamera.py”, line 219, in Update
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\ui\camera\cameraUtil.py”, line 319, in Update
File “C:\BuildAgent\work\bd8c56c3aa04df82\eve\release\TRANQUILITY\eve\client\script\ui\camera\cameraUtil.py”, line 104, in GetBallPosition

Before that, there are about 10-15 repeated stacktraces in the log, all similar to:

STACKTRACE #72 logged at 09/20/2018 14:53:36 : Client is using a session bound remote object while the session is mutating or changing. If the caller isn’t careful, this may be really bad…

Seems like this service starts right before the crash:

Service structureDeployment Startup time: 0.635s which proves my suspicion this is an issue related to drawing geometry, in this case, structures.

1 second before that, the following is logged:

STACKTRACE #9 logged at 09/23/2018 17:14:16 : Possible service deadlock detected!

Common path prefix = c:/buildagent/work/bd8c56c3aa04df82/eve/release/tranquility

Traced at:
<pre>/packages/bluepy/__init__.py(36) CallWrapper
<pre>/eve/client/script/ui/inflight/navigation.py(614) OnMouseMove
<pre>/carbon/common/script/sys/serviceManager.py(299) GetService
ms = None
self = <carbon.common.script.sys.serviceManager.ServiceManager instance at 0x13C19A58>
serviceName = 'structureDeployment'
srv = <eve.client.script.ui.services.structure.structureDeployment.StructureDeployment object at 0x26F4D310>

Thread Locals: session was <Session: (sid:3900469358807651207, clientID:0, mutating:0, contextOnly:False, locationid:30003133, corprole:0x0, userid:13368049, languageID:EN, role:0x6000040000000000L, charid:96814138, address:89.205.57.217:56650, userType:21, sessionType:5, regionid:10000039, constellationid:20000458, allianceid:498125261, corpid:98362674, shipid:1028633118799, solarsystemid:30003133, solarsystemid2:30003133, hqID:60013867, rolesAtAll:0x0, rolesAtHQ:0x0, rolesAtBase:0x0, rolesAtOther:0x0, genderID:True, bloodlineID:7, raceID:8)>
Stackhash: 1380088347
Reported from: logmodule
STACKTRACE END

Confirmed across 3 runs

Ping @CCP_Falcon @CCP_Bartender

Edit: I noticed the following as well:

EXCEPTION #7 logged at 23/09/18 17:49:24 : Unexpected exception raised from UpdateCamera
 
Formatted exception info:
AttributeError: typeID
 
Common path prefix = c:/buildagent/work/bd8c56c3aa04df82/eve/release/tranquility/eve/client/script
 
Caught at:
<pre>/parklife/sceneManager.py(131) _UpdateActiveCamera
<pre>/parklife/sceneManager.py(140) _UpdateCamera
 
Thrown at:
<pre>/parklife/sceneManager.py(136) _UpdateCamera
<pre>/ui/camera/baseCamera.py(101) _Update
<pre>/ui/camera/tacticalCamera.py(216) Update
<pre>/ui/camera/tacticalCamera.py(47) LookAt
<pre>/ui/camera/baseSpaceCamera.py(192) CheckObjectTooFar
        ball = <BlueWrapper: destiny.ClientBall (34922C48)>
        itemID = 1028633118799L
        self = <TacticalCamera at 773057520. eyePos=(-40000, 40000, 40000), atPos=(0, 0, 0), eyeOffset=None, atOffset=None, eyeAndAtOffset=None, minZoom=700000, maxZoom=100, isActive=True, fov=1.0>
 
Thread Locals:  session was <Session: (sid:976178672992300349, clientID:0, mutating:0, contextOnly:False, locationid:30003133, corprole:0x0, userid:13368049, languageID:EN, role:0x6000040000000000L, charid:96814138, address:89.205.57.217:41157, userType:21, sessionType:5, regionid:10000039, constellationid:20000458, allianceid:498125261, corpid:98362674, shipid:1028633118799, solarsystemid:30003133, solarsystemid2:30003133, hqID:60013867, rolesAtAll:0x0, rolesAtHQ:0x0, rolesAtBase:0x0, rolesAtOther:0x0, genderID:True, bloodlineID:7, raceID:8)>
Stackhash: 697642014

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.