Crash in linux (post 2.0.1 update)

Avatar
audiophiel
  • updated
  • 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
Duplicates 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

Replies 78
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
anonymous
  • Completed - Resolved

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

Avatar
2
anonymous
  • Under Review

We're trying to find the cause of this

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
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
Lee "Noontide" Moon
  • Marked for Review
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
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
anonymous
  • Pending Customer

Hey aszlig,


Could we get your Player.log?


Posting Output Logs

Avatar
0
aszlig

Ah, this is exactly the same issue I've noticed, but I didn't dig further so far. It doesn't happen if you strace the program so I'd assume that it happens because of a race condition.


Quickly looking through the disassembly, it seems that the crash is happening during object allocation (new operator). However the whole blurb is inlined, so without debugging symbols it will take a while to dissect.


Here is the core dump (894MiB, XZ-compressed, 6.7 GiB uncompressed) of the crash in version 2.0.3f1 from GOG, which should help in pinpointing the problem.