Out of curiosity, were my assumptions correct that the cause was a geometry shader?

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

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.

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:

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.

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.

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>.

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.

To make patching this less tedious I now implemented a generic patcher for common problems in games using Mono, so this is what needs to be patched for WFTO, at least for the settings and saving/loading. I didn't test the editor though...

Note that I'm still on version 2.0.1 because the GOG version hasn't been updated to 2.0.2. If it's been fixed in 2.0.2 already feel free to close :-)