KSP 1.1 crashes on startup (and kills X session)

[evilwombat]

Hello Linux x86_64 here, Ubuntu 14.04 LTS, Gnome Classic (metacity, no compiz or other graphical crap), nvidia-340. I am seeing a fairly consistent crash on startup. I am running a 2x 1920x1080 setup, but the problem happens even in single-monitor mode. After launching KSP_x86_64, a black game window appears (sized to be about 1920x1080, plus window decorations). A few seconds later, the (still black) game window flickers, killing my window manager, all running Xorg clients, and my entire Xorg session, meaning that I have to log in again. This is quite reproducible.

I found that the problem is a lot less likely to happen if I edit ~/.config/unity3d/Squad/Kerbal Space Program/prefs and delete any lines containing 'Screenmanager'. However, usually these lines will return if the game is restarted, meaning that I have to do this every time the game starts. Sometimes, even deleting the screenmanager lines does not prevent the game from crashing the whole graphical interface, but it generally helps. Any thoughts?

Edit to add: These are the lines that I have to delete in 'prefs'. I imagine the actual resolution is a little lower than 1920x1080, due to sizes of window borders and window decorations. Perhaps Unity's initial attempts to attain this resolution (before KSP does its own internal window resize) is what's causing the disaster.

        <pref name="Screenmanager Is Fullscreen mode" type="int">0</pref>
        <pref name="Screenmanager Resolution Height" type="int">1053</pref>
        <pref name="Screenmanager Resolution Width" type="int">1912</pref>

During the startup phase (before the screen with the progress bar and three kerbals), it is very easy to crash the game (and the window manager, and X) just by trying to move the game window or to resize it.

[lukeoftheaura]

Same bug, but I get as far as "made with unity" before I have to restart my xsession.

[senden9]

Same Problem. Here you can find a very verbose log of my system from Nvidia (uploaded because it is relatively large and i have no permission to upload in the forum). The next few lines show the stack trace from KSP:

           PID: 8300 (KSP.x86_64)
           UID: 1000 (USERNAME)
           GID: 1000 (USERNAME)
        Signal: 6 (ABRT)
     Timestamp: Sat 2016-04-23 18:46:15 CEST (19min ago)
  Command Line: /home/USERNAME/spiele/KSP_linux/KSP.x86_64
    Executable: /home/USERNAME/spiele/KSP_linux/KSP.x86_64
 Control Group: /user.slice/user-1000.slice/[email protected]/dbus.service
          Unit: [email protected]
     User Unit: [email protected]
         Slice: user-1000.slice
     Owner UID: 1000 (USERNAME)
       Boot ID: 7130b4462fdb47e6a4a15fe7d39c134f
    Machine ID: a01ef40d74ee4414826f317ba7e29803
      Hostname: USERNAME-PC
      Coredump: /var/lib/systemd/coredump/core.KSP\x2ex86_64.1000.7130b4462fdb47e6a4a15fe7d39c134f.8300.1461429975000000000000.lz4
       Message: Process 8300 (KSP.x86_64) of user 1000 dumped core.
                
                Stack trace of thread 8300:
                #0  0x00007f3da28a32a8 raise (libc.so.6)
                #1  0x00007f3da28a472a abort (libc.so.6)
                #2  0x00007f3da0f9a976 n/a (libmono.so)
                #3  0x00007f3da4095e80 __restore_rt (libpthread.so.0)
                #4  0x00007f3da28a32a8 raise (libc.so.6)
                #5  0x00007f3da28a472a abort (libc.so.6)
                #6  0x00007f3da28df369 __libc_message (libc.so.6)
                #7  0x00007f3da28e4d96 malloc_printerr (libc.so.6)
                #8  0x00007f3da28e557e _int_free (libc.so.6)
                #9  0x000000000067669e n/a (KSP.x86_64)
                #10 0x00000000006874b9 n/a (KSP.x86_64)
                #11 0x0000000000476ac7 n/a (KSP.x86_64)
                #12 0x0000000000759085 n/a (KSP.x86_64)
                #13 0x00000000007596a6 n/a (KSP.x86_64)
                #14 0x000000000072a9d5 n/a (KSP.x86_64)
                #15 0x0000000000461f38 n/a (KSP.x86_64)
                #16 0x00007f3da2890710 __libc_start_main (libc.so.6)
                #17 0x000000000046b4ed n/a (KSP.x86_64)

Maybe this can help someone to find the bug or a workaround.

Edit: It it help somebody i can also provide the coredump.

Edit 2: Add another stack trace:

           PID: 12845 (KSP.x86_64)
           UID: 1000 (USERNAME)
           GID: 1000 (USERNAME)
        Signal: 6 (ABRT)
     Timestamp: Sat 2016-04-23 19:24:36 CEST (2min 17s ago)
  Command Line: ./KSP.x86_64 -force-gfx-direct
    Executable: /home/USERNAME/spiele/KSP_linux/KSP.x86_64
 Control Group: /user.slice/user-1000.slice/[email protected]/dbus.service
          Unit: [email protected]
     User Unit: [email protected]
         Slice: user-1000.slice
     Owner UID: 1000 (USERNAME)
       Boot ID: 7130b4462fdb47e6a4a15fe7d39c134f
    Machine ID: a01ef40d74ee4414826f317ba7e29803
      Hostname: STEFANO-PC
      Coredump: /var/lib/systemd/coredump/core.KSP\x2ex86_64.1000.7130b4462fdb47e6a4a15fe7d39c134f.12845.1461432276000000000000.lz4
       Message: Process 12845 (KSP.x86_64) of user 1000 dumped core.
                
                Stack trace of thread 12845:
                #0  0x00007feed02ab2a8 raise (libc.so.6)
                #1  0x00007feed02ac72a abort (libc.so.6)
                #2  0x00007feece9a2976 n/a (libmono.so)
                #3  0x00007feed1a9de80 __restore_rt (libpthread.so.0)
                #4  0x00007feed02ab2a8 raise (libc.so.6)
                #5  0x00007feed02ac72a abort (libc.so.6)
                #6  0x00007feed02e7369 __libc_message (libc.so.6)
                #7  0x00007feed02ecd96 malloc_printerr (libc.so.6)
                #8  0x00007feed02ed57e _int_free (libc.so.6)
                #9  0x00000000005a5558 n/a (KSP.x86_64)
                #10 0x00000000005813fc n/a (KSP.x86_64)
                #11 0x0000000000578744 n/a (KSP.x86_64)
                #12 0x000000000047416a n/a (KSP.x86_64)
                #13 0x0000000000476abb n/a (KSP.x86_64)
                #14 0x0000000000759085 n/a (KSP.x86_64)
                #15 0x00000000007596a6 n/a (KSP.x86_64)
                #16 0x000000000072a9d5 n/a (KSP.x86_64)
                #17 0x0000000000461f38 n/a (KSP.x86_64)
                #18 0x00007feed0298710 __libc_start_main (libc.so.6)
                #19 0x000000000046b4ed n/a (KSP.x86_64)

 

Edited April 23, 2016 by senden9
new trace

[evilwombat]

For me, the X session restarts all on its own, presumably due to the window manager not liking size abuse (how on earth...?). I should point out that in addition to the screenmanager workaround, I had to synlink libpulse-simple.so.0 to /dev/null (inside the KSP directory) and launch KSP with LD_LIBRARY_PATH=. or else it aborts even before getting to the point of (maybe) crashing the window manager.

[senden9]

Thanks evilwombat,

now i can start the game. The game crashed "only" once since this fix.

Edit: It works 3/5 of the time…

Edit 2: And from time to time the game crash when while i play …

Edited April 24, 2016 by senden9
see above

[Michael Yoo]

Also just experienced this issue. Vanila install with fresh settings and no mods.

Removing

-force-gfx-direct

From the launch options fixed the crashing for me. See if it works for you.

 

With the AMD Catalyst driver the game would crash without that option, but it seems to be the opposite now that I've moved to the open source driver.

[evilwombat]

Thanks. I've had a little more success after I realized that the 'Screenmanager' nonsense in the 'prefs' file gets saved back to the file every time you exit the game. So, it's been standard procedure to delete the 'Screenmanager' lines from 'prefs' on *every* startup. Yeah, I should write a script.

I am not using steam, so I don't have any launch options, so I don't think "-force-glx-direct" applies to my situation... Maybe I can try *adding* and see if that helps

[inv]

It seems, that it is not exclusively a KSP problem... I've found this topic, when I was looking for the solution for the same problem with superhot. I also had a problem with KSP recently after an update to 5.5. So, apparently, unity5 based games are causing X session to restart.

[evilwombat]

The Linux version *still* fails to launch (two months later) with a "player initialization error" if Patcher is used. The version downloaded from the KSP Store works, kind of - every other launch, Unity gets into a situation where it starts madly resizing the game window on startup, until the window manager runs out of memory and is killed. This happens in a matter of seconds. Deleting the size/screen selection from 'prefs' helps, but only about half the time.

Versions prior to 1.1 did not have this problem.

I know everyone thinks that Xpox and PS4 are the next shiny things, but can existing, paying customers get some bugfixes, please?

[evilwombat]

Problem still happens. KSP developers are working on console ports, but existing paying users still have to deal with Unity getting into an infinite-resize loop and taking down the rest of the desktop environment with it. Plus, the Patcher repo still points to a KSP instance that is outright busted, to the point where it won't even start (for months now). Since v1.1.3, the workaround of deleting the screenmanager crap from 'prefs' no longer works. Come on.

Is there no way to force Unity to operate at a fixed geometry, and stop trying to alter the size of the game window more than ONCE during startup? Come onm guys. I've been with you since 0.2whatever.

Edited August 10, 2016 by evilwombat

[sal_vager]

The repo is fine, it's the patcher itself and it's being worked on.

You can force Unity to use specific resolutions, there are a number of command line options here.

These are likely what you need.

Quote

-screen-fullscreen	Overrides the default fullscreen state. This must be 0 or 1.
-screen-height	Overrides the default screen height. This must be an integer from a supported resolution.
-screen-width	Overrides the default screen width. This must be an integer from a supported resolution.
-screen-quality	Overrides the default screen quality. Example usage would be: /path/to/myGame -screen-quality Beautiful
-show-screen-selector	Forces the screen selector dialog to be shown.

As for fixing this, Squad will continue to update to newer versions of Unity as they become available.

[evilwombat]

Thanks. I appreciate the effort, but the Unity options don't do jack excrementse. Well, that's not entirely true. The -screen-width and -screen-height options *do* in fact set an *initial* screen resolution. As soon as I launch KSP.x86_64, I get a black window sized to the dimensions I specified. However, after a few seconds of showing a black window, the game will either resize itself to whatever was configured using the KSP Graphics options, or it will start madly resizing itself until it occupies the entire screen and the entire window manager crashes (killing off any other graphical applications that were open at the time, and kicking me out to the login screen).

So, no. Unity (or the game) still insist on forcing a screen size, and they still try to fight the window manager (classic metacity) until the WM runs out of memory. Normally I wouldn't be a cheeks hole about this type of nonsense, but (a) paying customer and (b) it's been months, and despite my love for the KSP developers, the situation at hand is nevertheless frustrating. Especially so because this wasn't a problem prior to 1.1, and the crash takes down the whole damn desktop environment with it.

As for the Patcher, hmm. I am able to run Patcher and it completes rsync successfully. Problem is, the resulting game instance is unplayable, and I have to log back into the KSP Store and download a fresh copy (or unzip the local archive if I kept it).

Edited August 11, 2016 by evilwombat

[sal_vager]

And the patcher is still using the same repo as the store copy, so it's not the repo

What you describe with resolutions @evilwombat does not occur for me, so I can't test any of the workarounds, the one that I think you need is OOM killer, by @Psycho_zs

This seems to be a bug between Unity3D and the Gnome and Unity desktop environments, it doesn't occur on xfce or lxde.

As before though, make sure you delete the prefs file, that should force Unity to make one with the KSP resolution settings.

There's no way to disable prefs unfortunately, it's created by Unity3D for all Unity3D games on Linux and OSX, its windows equivalent is the windows registry key for each field.

 

Also don't swear on the forums.

[evilwombat]

Hmmm. Indeed, I have noticed the problem happens (at least, more) frequently on Gnome (Metacity) than on something more basic (twm). But, I am not running any fancy Gnome screen effects, or even the Unity environment (not to be confused with Unity the game engine - argh).

I do indeed delete the 'prefs' file (or rather, overwrite it with a version without any of the ScreenManager options in it) on every startup, but this workaround stopped working in v1.1.2 / v1.1.3. Still no luck.

The Unity resolution options don't seem to be the problem per se anymore. The game starts (with just a black window) using Unity size settings, but the mad resizing only right about when the Squad logo is about to appear. In some instances, the window resizes *once* and the game starts, but in others, the window grows out of control in a matter of less than a second. This makes me believe that the resizing / crash problem is not due to Unity internals, but due to something KSP code is doing as part of its startup sequence (like resizing the window again, this time to match the screen dimensions found in settings.cfg rather than in prefs).

It's interesting that another user had a similar problem. While trying to catch this problem in the act, I managed to kill KSP an instant before it took down X. As it turns out, the memory leak is not within X itself (I don't think...) but within the window manager (metacity), as evidenced by a large amount of memory being freed if I kill/relaunch the WM without relaunching X. It makes sense that a giant burst of window resizing (and fighting the window owner) could bring out gremlins. I just wish KSP made a single attempt to resize itself and then left the dimensions alone. Sometimes this problem can even be triggered by inadvertently dragging the game window to a new location on screen. Sigh.

Anyway, what is needed to diagnose this further? I am not sure what the exact logic is that KSP uses to set its screen dimensions, but clearly this happens in two steps (once on startup, through prefs, and the second time, through settings.cfg). Maybe the settings.cfg mechanism is being a bit too aggressive. Shrug.

Edited August 11, 2016 by evilwombat

[sal_vager]

You mention dragging the window @evilwombat, do you do this when KSP starts or do you leave KSP alone?

I say this because this is what I see when I drag the window, though it does not crash and doesn't happen when I leave the window alone.

Unity3D starts first, sets the screen resolution to the contents of the prefs file, then Unity3D starts KSP, the very first thing KSP does is show the monkey head screen, there's nothing before that point that is Squads.

Even the KSP.exe/KSP.x86 is just a generic Unity3D binary file, and is interchangeable with the binary from any other Unity game.

If that is what you see then I do see this, I thought it was something else.

[evilwombat]

Hmm. I generally leave the KSP window alone. Since it seems to be sensitive to window size (and possibly position), I generally leave it untouched as the game is running. Usually the window can be moved without incident, but once or twice I've had some sloppy mouse movement resulting in the window getting "touched" in a way that brought out the problem. But I'm less worried about that, and more worried about simple startup killing off the X session.

Here's what mine does (half the time): https://dl.dropboxusercontent.com/u/79740546/VID_20160812_035954.mp4
You can see why a screen recording program would have been unuseful here

In some cases, the KSP window becomes outright huge (spanning the entire screen width) maybe a split second prior to the whole environment imploding, though this video does not capture that particular behavior.

In the cases where the game DOES successfully start up, I do see a distinct moment where the window is resized. That is, the game starts up using some Unity default size (controllable through command line options you specified), and the game window remains this way (with no content) for the first few seconds after launch. A few seconds later, window resizes itself to match the dimensions set in persistent.cfg (this happens right when the monkey head appears).

Edited August 12, 2016 by evilwombat

[sal_vager]

Have you tried without LD_LIBRARY_PATH= ?

I usually just click the .x86 or .x86_64 directly, or cd to the folder and run KSP with no arguments.

[evilwombat]

I need the LD_LIBRARY_PATH part because I don't have Pulseaudio installed on my system, and instead, I have a local symlink called libpulse-simple.so.0 (whatever that's called) to /dev/null. Or has that been fixed in v1.1.3?

Edited August 13, 2016 by evilwombat

[sal_vager]

Nah that's meant to be fixed in a later version of Unity3D than is used by KSP 1.1.3

Another workaround is pulsenomore by kspflo which is essentially the same, available here.