+2
Lõpetatud

Crash in linux (post 2.0.1 update)

audiophiel 10 kuud tagasi • uuendaja Cian Noonan (Development Support Engineer) 9 kuud tagasi 78 3 duplikaadid

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

Duplikaadid 3

the window freezes for about 15seconds, and then vanishes completely

tried this

but without success

Lõpetatud

Great! Glad to hear it, let us know if you have any further issues

I just experienced another crash even after unchecking Steam Overlay. But they are far more uncommon now than when I had Steam Overlay enabled.

Pending Customer

Reopening as the issue has not been resolved. 


Please include a log from the latest crash.

I have merged these two tickets as they are referring to the same issue. We will get back to your with what to do next soon

Sadly no crash logs are created and the crashes are instant. Here is the player log tho Player.log


I have tried verifying integrity game files, clearing download cache et cetera, for no avail.

I have the same problem as Insantyz.

The game randomly crashes after a couple of minutes. No crash log is created only a  Player.log that indicates a similar (same?) Segfault as in his log. Disabling steam overlay didn't make a difference.

I bought the game only yesterday, so I can't say what changed when the issue first came up.

Pending Customer

The Segfault points to the SteamOverlay crashing, not the game.


Could you all please try to go to the games properties in Steam and see if using the beta tab to roll back to the last build fixes this for you?


There should be a "PreviousBuild" branch that you can use

Just to be clear: You mean this 2.0f10?


Thanks,

audiophiel

I clicked at this option, and now i tested it and it still crashed with the same symptoms as before. I wanted to double check the options you mentioned, but now the window looks different:


The "previousbuild" option is the one which was active during the latest test.


Thanks

audiophiel

If thats the case please try "previousmajorbuild"

Pending Third Party

This is a issue that has now been localised to the update of our 3rd party UI middleware. Please all move to the "LinuxStable" branch until further notice

LinuxStable branch works perfectly, thank you!

no crashes so far in the linuxstable branch

edit: even with steam overlay enabled

Pending Customer

Hey YS1,


This is a know issue that we are currently investigating, please in the meantime switch to the Linux stable branch. To do so follow these steps:


  1. Right-Click WFTO in Steam
  2. Click "Properties" in the drop down menu
  3. Navigate to the "Betas" tab in the Properties window
  4. Click the dropdown and select "LinuxStable"
  5. Close the windows and let the game update

This should mitigate the crashes until we have corrected this crash on the default branch

Pending Customer

We are releasing a patch later today/tomorrow that may fix this, when 2.0.3 is live can you please move back to the default beta branch by selecting "NONE" in the drop down and seeing if you continue to crash

I tried both


sry to say but 2.0.3 is still crashing

i could play for an hour

but than it crashed and if i reload the savegame is continues to crash after some time



the LinuxStable did not crashed

but it has my other show stopper bug

the circling Imps Bug

so thats not an alternative

Marked for Review

Setting back for us to review and determine next steps. We believe that the crash is occurring due to recent versions of the Coherent GT Middleware. What we don't know is the factor behind why this is occuring as we are unable to replicate the crash on our own Linux machines.

Ok

would it help if we would collect some information about our used hardware?

maybe its one component or the desktop environment

As i already see the thread starter has has a more or less similar configuration like mine

different distribution and Kernel

but

Intel processor (it's the same)

Nvidia graphics (different model 750 / 950)

and we both use KDE


Did you tried this combination Intel / Nvidia and KDE on you test machines?

Pending Third Party

We are already able to replicate the crash, this has been passed onto our Middleware provider who are now investigating.

Just to let you know, I have the same issue. Since the update, it will let me load in the game. The mouse seems quite laggy. I move around the menus no problem. As soon as I try to click the play button, it just crashes straight out to Desktop. Using Linux Mint 17.3. Have turned off the steam overlay, still crashing. I am just downloading the last Linux Stable to see if that works. Will update to let you know.

Now running the LinuxStable 2.0f10. This seems to be working as normal. Click to play a game and it loads, no issue. Hopefully this is a Middle ware issue that they can fix. Still annoys that these companies forget that the Linux community is not going away, in fact I would say that it keeps growing.

We will keep this thread up to date with any info we receive from our Linux middleware provider

We are now releasing a version of the linux build to the default branch that should work around the issue. Please try and download 2.0.3f1

This version is not starting

at least on my pc


i have just the made with unity logo

and then a black screen with mouse and a trial version writing

A failure in our build process has broken the linux build. This will be fixed in the next update in the next hour

Tried the new version

but sadly it crashed again

Marked for Review

Marking for review as the crash is not resolved in the latest version.

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.

Pending Customer

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

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.

+2

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.

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.

+2
Under Review

We're trying to find the cause of this

Lõpetatud

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.

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

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

Hey aszlig,


Your debugging work was incredibly helpful in pinning down the cause. An experimental rendering feature "Graphics Jobs" was activated in the project without enough scrutiny. Once we knew that we were causing OpenGLES to crash we were able to determine this much faster. Disabling this rendering pipeline has restored stability on all Linux platforms. 

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

What level was this on StormBeast?


Does the game hold that much memory during play?

This was after about 1 hour of play on the first level of Undergames campaign playing as Kasita.

I'm not sure how much memory the game usually takes up unfortunately, I'll have to check in another game this evening. Still strange that the process would persist after exiting the game though.

I must have a different issue on Linux then, as I am still unable to play. I have disabled the steam overlay. I have checked the integrity of local files. I can go all the way through every menu, but when I finally press "PLAY", it just drops straight back to desktop. Any suggestions?

A log would be good battyman, also please make sure that you're on 2.0.4

~/.config/unity3d/Subterranean Games/War For The Overworld/Player.log


Player.log
As requested, a player log from this morning. Should I be opening another post for this, as you have already marked this issue as completed.

Will look into this. Might need to upgrade my Linux Version.

You could also try the gernal crash troubleshooting:


Crash!

Hello,
WFTO 2.0.4 freezes here after 2 minutes of play in the "slap 100 dwarfs" scenario.Player.log

Kubuntu 18.04 with kernel 4.17.0-996-generic ; NVIDIA Quadro K620 with driver 396.45.

Does it crash on any other map? that is likely just an issue with that level

~/.config/unity3d/Subterranean Games/War For The Overworld/Player.log
It happened again after 20 min with another map (king of the underhill game). This time I was using the nouveau driver and not the NVIDIA closed one.

Does this still happen if you disable the steam overlay in the games properties window on Steam?

As far as I know, Steam Overlay has never been activated, globally.

I'm sorry we are at a dead end here. I can only imagine that it is something to do with the nouveau driver.


The crash you had with the NVIDIA Proprietary driver should only occur on the Slap-A-Dwarf map should only occur on that map.


If you crash again on a different map (Not slapa dwarf) with the NVIDIA Proprietary driver then we can look into it.

Can confirm that after the small patch that came through today, my issue is no longer present.

Thanks guys and thanks for the great game, and also bringing it to Linux!

Great! Please let us know if any of you have any further issues