Kerbal Space Program

Filed this as low priority because most distributions come with Pulseaudio by default. Hope that's appropriate.

Judging from that thread they are on it though, so that's good.

I see. This is a deal breaker for me as I rely on advanced ALSA functionality and will have no sound at all (in any application) if pulseaudio is running. I cannot uninstall it completely either, as large parts of the system are linked against it's libraries.

I don't think this is low priority BTW, to quote the priority table:

Critical: A large portion of the game is unplayable.

"large portion unplayable" covers "CTD on startup", right?

I'd love to help with finding a workaround I can actually use, but I don't own KSP on steam. Options?

It does, but I had to remove the library it looks for from Steam's Linux runtime - not brilliant.

Is there a way to inform KSP that it should not use Steam's runtime? I don't have PulseAudio installed (though I do have libpulse, so if that's what breaks FMOD then this won't help), but the Steam Runtime does have it, and I have all the other libraries Kerbal Space Program needs.

If it's useful, here's the result of the crash when running KSP in GDB:

Program received signal SIGPWR, Power fail/restart.
[Switching to Thread 0x7ffff1835700 (LWP 7307)]
0x00007ffff79c60c9 in futex_abstimed_wait (cancel=true, 
    private=<optimized out>, abstime=0x0, expected=0, futex=0x7ffff247e070)
    at sem_waitcommon.c:42

(gdb) step

Program received signal SIGXCPU, CPU time limit exceeded.
0x00007ffff60fa657 in do_sigsuspend (set=0x7ffff2480900)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:29

Every thread dies to these signals, until finally:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fc6780 (LWP 7363)]
0x0000000000b4acfa in ?? ()

Program received signal SIGABRT, Aborted.
0x00007ffff60fa267 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:55
55    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) 
Continuing.
[Thread 0x7fff937fe700 (LWP 7392) exited]
[Thread 0x7fffe802c700 (LWP 7399) exited]
[Thread 0x7fff92ffd700 (LWP 7393) exited]
[Thread 0x7fff93fff700 (LWP 7391) exited]
[Thread 0x7fffb0ff9700 (LWP 7390) exited]
[Thread 0x7fffb17fa700 (LWP 7389) exited]
[Thread 0x7fffb1ffb700 (LWP 7388) exited]
[Thread 0x7fffb27fc700 (LWP 7387) exited]
[Thread 0x7fffb2ffd700 (LWP 7386) exited]
[Thread 0x7fffb37fe700 (LWP 7385) exited]
[Thread 0x7fffb3fff700 (LWP 7384) exited]
[Thread 0x7fffd4ff9700 (LWP 7383) exited]
[Thread 0x7fffd57fa700 (LWP 7382) exited]
[Thread 0x7fffd5ffb700 (LWP 7381) exited]
[Thread 0x7fffd67fc700 (LWP 7380) exited]
[Thread 0x7fffd6ffd700 (LWP 7379) exited]
[Thread 0x7fffd77fe700 (LWP 7378) exited]
[Thread 0x7fffd7fff700 (LWP 7377) exited]
[Thread 0x7fffe8dac700 (LWP 7376) exited]
[Thread 0x7fffe95ad700 (LWP 7375) exited]
[Thread 0x7fffe9dae700 (LWP 7374) exited]
[Thread 0x7fffea5af700 (LWP 7373) exited]
[Thread 0x7fffeb5b1700 (LWP 7371) exited]
[Thread 0x7fffebfff700 (LWP 7370) exited]
[Thread 0x7ffff1634700 (LWP 7369) exited]
[Thread 0x7ffff1835700 (LWP 7368) exited]
[Thread 0x7ffff18c6700 (LWP 7367) exited]
[Thread 0x7ffff7fc6780 (LWP 7363) exited]

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.

All of my log files from #7514 belong over here. I tried the suggestions on that thread in vain, but turning pulseaudio back on fixed the problem I was having. Can those attachments be transferred by a moderator?

silverwingedseraph wrote:

Is there a way to inform KSP that it should not use Steam's runtime?

IIRC, steam just launches the binary with LD_LIBRARY_PATH set... so launching KSP outside of steam should do what you ask.

On that note, removing libpulse from the steam runtime should work for steam users, but copes from the store (when it drops) are going to be using system libs... and you can't remove the system copy of libpulse without a heap of collateral damage.

How practical would shipping a "steamified" (bundle the steam runtime, it's FOSS right?) version from the store be? at least then there's a workaround for those (like me) who cannot/will not install the pulse binaries.

Bundling the steam runtime would also solve any other distro-specific weirdness, as KSP would be using Ubuntu libraries.

You could always hide your system Pulse libraries using a mount namespace. Let me see, if I can whip something up.

KSP isn't the only game affected by this (Stardrive 2 also has this issue, for example), I'd hope that Unity fixes this problem soon:

http://forum.unity3d.com/threads/several-games-segfault-at-fmod-failed-to-get-number-of-drivers-when-pulseaudio-isnt-running.369943/
http://forum.unity3d.com/threads/failed-to-get-number-of-drivers.377026/#post-2544187

kspflo wrote:

I believe to have developed a functional workaround using the approach I alluded to earlier. It's an ugly hack, but it should work.

Thanks boss, I'm not sure I like this approach, but I guess it's no more ugly than the ld_preload hack I was contemplating.
Since I haven't actually gotten around to implementing my idea, I'll gladly take yours :)
I don't actually have access to the prerelease, so testing it will have to wait. :(

it's no more ugly than the ld_preload hack

I disagree, LD_PRELOAD wouldn't require root access.

Well, I had most of the mount namespace code lying around, so it was less work for me then writing an LD_PRELOAD "solution" from scratch. You're of course free to come up with your own hack or wait for a Unity fix.

kshade wrote:

I disagree, LD_PRELOAD wouldn't require root access.

That is a point, though there's nothing particularly dangerous in there.
I might have a poke at my idea but I kinda need the game for that, as otherwise I don't know which syscalls to hijack ;). Later perhaps.

steve_v wrote:

I might have a poke at my idea but I kinda need the game for that, as otherwise I don't know which syscalls to hijack ;). Later perhaps.

$ strace -fe trace=file ./KSP.x86_64 2>&1 | grep libpulse.so
[pid  6925] open("/usr/lib64/pulseaudio/tls/x86_64/libpulse.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  6925] open("/usr/lib64/pulseaudio/tls/libpulse.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  6925] open("/usr/lib64/pulseaudio/x86_64/libpulse.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  6925] open("/usr/lib64/pulseaudio/libpulse.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  6925] open("/usr/lib64/libpulse.so.0", O_RDONLY|O_CLOEXEC) = 21

Personally, I dislike the idea of intercepting open() even more and consider the namespace approach a bit more surgical.

kspflo wrote:

No prior stat() or access(). Good luck!

Arse.

Personally, I dislike the idea of intercepting open() even more and consider the namespace approach a bit more surgical.

Yeah, so do I TBH. I might still code this up at some point, (my free-weekend is rapidly vanishing) but I was hoping to leave open() alone.
For the present I think I'll just nick yours & file it until release. :)

Third approach: I loaded up the binary in ghex, looked for libpulse-simple and replaced the l with an x. Strace confirms that it's now trying to load a library that doesn't exist:

open("/lib64/tls/x86_64/libpuxse-simple.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls/x86_64", 0x7ffc7523e530) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libpuxse-simple.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...

kspflo: Wasn't trying to be a dick to you by the way, I think your approach is actually pretty cool - it's just not something I can see as an "official" workaround.

kshade wrote:

kspflo: Wasn't trying to be a dick to you by the way, I think your approach is actually pretty cool - it's just not something I can see as an "official" workaround.

No offence taken. Fully understand your reservations.

kshade wrote:

Third approach: I loaded up the binary in ghex, looked for libpulse-simple and replaced the l with an x. Strace confirms that it's now trying to load a library that doesn't exist:

So, for an enduser-friendly workaround, one could load the KSP exe into memory (memfd_create(), or a pipe + vmsplice() on Linux <3.17), patch it, and run it (fexecve()).
I'd add the memory roundtrip, so the file isn't restored by the patcher, if that's a concern. I have a Steam copy, I only ever read about the patcher in devnotes.
I'm genuinely curious how that would work and I might just try for the fun of it.

Isn't the non-Steam patcher just Launcher.x86_64? That's in the Steam distribution, just not used.

Another reason for writing a small executable that patches the executable: It could detect if Pulse is actually running, and skip/revert the patch if it is.

Little correction, libpulse-simple isn't the thing that needs "mangling", there are other references to PulseAudio that do. I'm not sure which one is the actual culprit.

kshade wrote:

Isn't the non-Steam patcher just Launcher.x86_64? That's in the Steam distribution, just not used.

AFAICT, the mysterious patcher is supposed to be retrieved by Launcher.x86[_64] - but it's been MIA for a long time, and gets an html page instead.

Another reason for writing a small executable that patches the executable: It could detect if Pulse is actually running, and skip/revert the patch if it is.

I like it.
That said, the accepted workaround for the last Unity SNAFU was just some arguments for xxd posted in the Linux thread... Not exactly "official", but it's been in use for some time.

Good idea, actually:

echo "013ab3d0: 006c 6962 7075 7873 652d 7369 6d70 6c65" | xxd -r - ~/.local/share/Steam/steamapps/common/Kerbal\ Space\ Program/KSP.x86_64

Turns out my previous comment wasn't right, it's just that one instance that needs replacing.

kspflo wrote:

New day, new hack.

kspflo, you are legendary. Thanks again for the effort on this one.
This thing is pretty elegant, I already have some unrelated ideas I might steal it for. ;)

I'll wait for someone without memfd_create() to come along first.

Looks like even Debian stable has it (backported), so with any luck this will never happen. :)

kspflo: Works perfectly fine from what I can see, thanks! I put it into the game's launch options like this:

/home/kshade/bin/pulsenomore.x86_64 %command%_64

Glad to hear it's working.

steve_v wrote:

kspflo, you are legendary. Thanks again for the effort on this one.

Thanks for the praise. If nothing else, it was educational. Tried a few things before I settled on this.

steve_v wrote:

This thing is pretty elegant, I already have some unrelated ideas I might steal it for. ;)

Steal away. ;)

steve_v wrote:

Looks like even Debian stable has it (backported), so with any luck this will never happen. :)

Yes, I was thinking about Debian. Good to know they backport these things.

kshade wrote:

%command%_64

kspflo wrote:

New day, new hack.

pulsenomore checks if Pulseaudio is running, if it is, executes the supplied program directly, otherwise loades the executable into memory, replaces "libpulse-simple.so.0" with "/dev/null", and then executes that.

It requires the memfd_create() syscall introduced in 3.17. I actually tried to provide a fallback (open() with O_TMPFILE), but the file descriptor must not be opened with write permission, or ETXTBSY is returned, when trying to execute it. If needed, one could of course write the patched file to disk, but I'll wait for someone without memfd_create() to come along first.
I disabled Pulseaudio autospawn and KSP crashed as expected. Using pulsenomore, it launches successfully.

No more setuid needed, just make it executable, and run it.

Edit:
Compile with: gcc -std=gnu99 -O2 -o pulsenomore pulsenomore.c -ldl

Thank you so much! Working perfectly here on Arch Linux x64. I run KSP with the following command: ./pulsenomore /<steamlibrary>/common/Kerbal\ Space\ Program/KSP.x86_64
I made an alias in .bashrc to make it easier.

I was wondering why it didn't work from Steam, didn't work when running KSP.x86_64 directly but did work when running KSP.x86: have pulse libraries installed for x86_64 but not for x86.
But I found a quite simple workaround:
run

ln -s /dev/null libpulse-simple.so.0

LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH %command%

Is there anyone for whom the workarounds do not work?

I have constantly had good success with my simple workaround of the symlink to /dev/null in a directory at the beginning of LD_LIBRARY_PATH
Setting that up (when no pulse is detected running) in a launcher shell script that is called instead of the binary could be the way to go. At least it does not require root and I prefer a simple shell script to a binary that does some black magic.

I use a script with bunch of stuff anyway, so adding this workaround was easy. It works.

Fixing this bug would require something like logic of 'pulsenomore' incorporated into KSP binary.