Crash in linux (post 2.0.1 update)

Avatar
audiophiel
  • Views 40 280
  • oppdatert
  • Completed - Resolved

Hey,
I bought the whole package in the summer sale, and started to enjoy it. But it keeps crashing after ~5-10min. Always. It is the current version, and I thought a lot of fixes where issued with that. Also, after the crash (and even after I stopped the steam process), a process called "WFTOGame.x86_64" runs with about 4GB of memory in use. If start the game again, another process with the same name appears. What can I do to make this game run smoothly without crashing all the time. My stats are:


OS: Manjaro Linux x86_64 
Kernel: 4.17.0-2-MANJARO 
DE: KDE 
WM: KWin 
CPU: Intel i5-6600K (4) @ 4.100GHz 
GPU: NVIDIA GeForce GTX 950 
Memory: 15984MiB 


What I tried so far:

Changing the resolution to the lowest and deactivated anti aliasing and the other option to recommended to deactivate. A crash log was not created, but a Player.log. 


Thanks for the help!


audiophiel


Game Version:
Steam Public
Platform:
Linux
Duplikater 3
Crash under Ubuntu 18.04
Avatar YS1

Since upgrading my computer from Ubuntu 16.04 to 18.04, WFTO crashes after some time playing a map. This happened both times I tried : once with a custom map (campaign from DK1) ; once in the HOG campaign.

Player.log

Game is crashing after some minutes

I have a new problem since todays patch 2.0.1

WftO is crashing every few minutes (10 minutes) randomly


I uploded my player.log

Player.log

Kommentarer 78
Avatar
0
aszlig
Quote from anonymous

Hey aszlig,


Could we get your Player.log?


Posting Output Logs

I run WFTO in a mount namespace with a tmpfs, so I don't have the Player.log anymore, but the backtrace is the same as in the provided core dump (and also the same as the one of the thread starter).

For reference:


#0 0x0000000000f973be in ?? ()
#1 0x0000000000f8f444 in ?? ()
#2 0x0000000000f2379b in ?? ()
#3 0x0000000000f2940b in ?? ()
#4 0x0000000000f1fa87 in ?? ()
#5 0x00000000008e8cc8 in ?? ()
#6 0x00007ffff79bc5a7 in start_thread () from libpthread.so.0
#7 0x00007ffff61cf22f in clone () from libc.so.6

Here is the disassembly around 0xf973be:


  f973a2:       45 0f b6 4f 02          movzbl 0x2(%r15),%r9d
  f973a7:       ba 04 00 00 00          mov    $0x4,%edx
  f973ac:       41 80 f9 02             cmp    $0x2,%r9b
  f973b0:       74 05                   je     f973b7
  f973b2:       41 0f b6 57 03          movzbl 0x3(%r15),%edx
  f973b7:       48 8b 40 30             mov    0x30(%rax),%rax
  f973bb:       83 f9 1b                cmp    $0x1b,%ecx
 >f973be:       8b 40 08                mov    0x8(%rax),%eax
  f973c1:       89 44 24 58             mov    %eax,0x58(%rsp)
  f973c5:       0f 86 6d 01 00 00       jbe    f97538
  f973cb:       c6 44 24 5f 00          movb   $0x0,0x5f(%rsp)
  f973d0:       45 31 ff                xor    %r15d,%r15d
  f973d3:       89 54 24 28             mov    %edx,0x28(%rsp)
  f973d7:       89 74 24 20             mov    %esi,0x20(%rsp)
  f973db:       44 88 44 24 18          mov    %r8b,0x18(%rsp)
  f973e0:       44 88 4c 24 30          mov    %r9b,0x30(%rsp)
  f973e5:       e8 16 fa 92 ff          callq  8c6e00


Note: The last callq is for the demangled symbol <operator new(unsigned long)@@base+0x27c9d0>.

Avatar
0
aszlig

For the sake of completeness, I just reproduced the issue by doing the first tutorial map with a fresh game state and here is the requested Player.log


Also note, that the first three lines are not relevant because it's the Mono crash handler.


PS: It could also help if you can provide us the DWARF (or any format you prefer) symbols for the executable, so we could help debugging.

Avatar
0
Lee "Noontide" Moon Designer & Community Manager
  • Marked for Review
Avatar
2
aszlig

Okay, I did dig deeper now and my first guess was pretty much inaccurate to say the least. Digging through the assembly however was quite nasty, because a huge chunk of code is inlined and the crash is inside a for loop containing a big switch statement.


However, if I didn't get confused, some of pointers for the vertex components didn't get initialized correctly, so a construct like this looks like it's the cause for the segfault:


&vertexdeclaration->channels[j]


Here j is some value derived from the iteration value of the for-loop (didn't yet check how it is derived though), which iterates from 0 to 27 (no idea yet why 27, but it looks like it's some enum).


So in summary: I'm pretty certain that this is caused by invalid initialization of some shader channels.


What I didn't yet find out is which one exactly, because from what I have observed it's still a Heisenbug :-/


Going check that on Tuesday or maybe even Monday if nobody else has found the invalid shader in the meantime (again, with debugging symbols it's only a matter of minutes to find out).


PS: It doesn't even necessarily need to be an invalid shader in the first place but could also be memory corruption, which would support my initial guess about a race condition.

Avatar
0
aszlig

Found some sources online which are pretty close to the code in question, and this is where the crash happens, so I think I wasn't that wrong after all with my analysis.


However, I still haven't figured out exactly when this is triggered, nor am I sure whether the linked code is a part of Unity3d or just got statically linked in by something else.

Avatar
2
anonymous
  • Under Review

We're trying to find the cause of this

Avatar
0
anonymous
  • Completed - Resolved

The latest patch has fixed this issue, please let us know how it goes for you all.

Avatar
0
aszlig
Quote from anonymous

The latest patch has fixed this issue, please let us know how it goes for you all.

Is the update just for Steam? Because on GOG the version for GNU/Linux is still at 2.0.3f1.

Avatar
0
Insantyz
Quote from anonymous

The latest patch has fixed this issue, please let us know how it goes for you all.

no crashes so far, will notify here if crashes are experienced with along with logs

Avatar
0
StormBeast

No crashes for me, but very low fps (This could just be the level I suppose). More interestingly, I have a "ghost" process of the game running, after exit, taking up a rather large chunk of memory - see attached screenshot. Might have crashed on a system with less RAM?

Arch Linux, kernel 4.17.11

KDE/Kwin

AMD Ryzen 1800x

Nvidia Proprietary latest (GTX1070)

32GB RAM



Player.log


Customer support portal powered by UserEcho