[Linux / Fatal Bug] DOA On Startup - Game Crashes with no error message except "Abort"

[Braden]

Let's just get right to the meat, shall we?

braden[5][pts8][~/.local/share/Steam/steamapps/common/Hook]$ ./hook.x86_64
Set current directory to /home/braden/.local/share/Steam/steamapps/common/Hook
Found path: /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64
Mono path[0] = '/home/braden/.local/share/Steam/steamapps/common/Hook/hook_Data/Managed'
Mono path[1] = '/home/braden/.local/share/Steam/steamapps/common/Hook/hook_Data/Mono'
Mono config path = '/home/braden/.local/share/Steam/steamapps/common/Hook/hook_Data/Mono/etc'
/dev/input/js0: driver version: 2.1.0 (20100)
/dev/input/js0: fd 3, buttons 11, axes 8, name Logitech Gamepad F310
/dev/input/js0: axis  0: raw      0, mapped 0.000000
/dev/input/js0: axis  1: raw     -2, mapped 0.000000
/dev/input/js0: axis  2: raw -32767, mapped 0.000000
/dev/input/js0: axis  3: raw      0, mapped 0.000000
/dev/input/js0: axis  4: raw     -2, mapped 0.000000
/dev/input/js0: axis  5: raw -32767, mapped 0.000000
/dev/input/js0: axis  6: raw      0, mapped 0.000000
/dev/input/js0: axis  7: raw      0, mapped 0.000000
/dev/input/js1: driver version: 2.1.0 (20100)
/dev/input/js1: fd 4, buttons 11, axes 8, name Microsoft X-Box 360 pad
/dev/input/js1: using XBox 360 Controller mappings
/dev/input/js1: axis  0: raw      0, mapped 0.000000
/dev/input/js1: axis  1: raw      0, mapped 0.000000
/dev/input/js1: axis  3: raw      0, mapped 0.000000
/dev/input/js1: axis  4: raw      0, mapped 0.000000
/dev/input/js1: axis  6: raw      0, mapped 0.000000
/dev/input/js1: axis  7: raw      0, mapped 0.000000
Aborted

As you can see, some kind of error has caused the game to abort, despite it being written in C#, which is a managed language. Here's what valgrind says: https://pastebin.com/raw/m5bbsQRv (way too long to paste here)


Your game seems to be throwing an exception that it doesn't feel like elaborating on, which is causing it to abort. If you don't know what I'm talking about, it's possible that the C# runtime itself is crashing because of an error in your code.

Aside from that, I am seeing a LOT of conditional jumps using uninitialized values, and other uses of uninitialized 64-bit values ("use of uninitialized value of size 8"). I also saw:

* write Syscall using uninitialized string

* a warning about using an address that is 47 bytes inside an alloc'd 4KiB block (I'm actually not sure what valgrind is getting at with this one)

* a similar warning, but this time 36 bytes in a 16KiB block

This is dangerous stuff, because in languages like C, we call this undefined behavior. It is not okay to use an uninitialized value for anything. Because its value could be literally anything. There is no guarantee, and thus an attempt to use it is dangerous. The compiler can do anything it wants and it will always be correct since standard says it's undefined. The compiler isn't obligated to do any specific thing, though usually, it will make the choice it deems the best for performance, which frequently results in an unauthorized memory access, causing the OS to kill the program with a SIGSEGV. The compiler might do something close to your intent, or it might abort the compilation altogether, citing that your program has undefined behavior, it might delete huge chunks of code during the optimization phase, reasoning that the instance of UB is illogical and thus not necessary, resulting in wildly different behavior that might go unnoticed for years[1], or it might result in the HeartBleed bug, input a nuclear launch code and destroy the world, go back in time and kill your parents, make demons fly out of your nose. The usual stuff. Depends on the compiler.

1. Example of UB: http://kqueue.org/blog/2012/06/25/more-randomness-or-less/

The question is, if the Mono C# runtime is invoking undefined behavior, then you are essentially building on a foundation that is, itself, broken. Shouldn't the managed language be implemented correctly before you write code on top of it? It's no wonder modern programs are so incredibly unstable. Can't get half of the Electron JavaScript apps to run because they crash for stupid reason. Can't install half of the python apps because the package manager for it is so incompetent that it can't do its job and manage dependencies correctly. Almost all of the unity games I play start up fullscreen and somehow manage to ♥♥♥♥ that up to the degree of unplayability.

And now your app, that I paid for, is crashing without specifying what exception is being raised to cause it to crash. And the only reason I know it threw an exception, is because valgrind says so. Meaning the only way I can give a meaningful bug report, is by showing you the valgrind output. So I have to hope that you have at least some experience with C, and can understand valgrind's output well enough to trace where the problem is.

If it's anything, again, it's PROBABLY this:

==402== Process terminating with default action of signal 6 (SIGABRT)
==402==    at 0x64AC428: raise (raise.c:54)
==402==    by 0x64AE029: abort (abort.c:89)
==402==    by 0xB5638AE: ??? (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook_Data/Mono/x86_64/libmono.so)
==402==    by 0x504F38F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.23.so)
==402==    by 0x64AC427: raise (raise.c:54)
==402==    by 0x64AE029: abort (abort.c:89)
==402==    by 0x1321F6C: __gnu_cxx::__verbose_terminate_handler() (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)
==402==    by 0x12E7E75: ??? (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)
==402==    by 0x12E7EA2: std::terminate() (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)
==402==    by 0x12E7A0D: __cxa_throw (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)
==402==    by 0x13128BC: std::__throw_logic_error(char const*) (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)
==402==    by 0xC7A789: ??? (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)
==402==

It's not the most helpful traceback in the world, because it's clearly referencing code that is layers beneath your program. But, it does uncover the reason for the program termination: OS sends SIGABRT because an exception was raise()'d. And the flow looks like this:

hook does an operation in (some function), resulting in a call to std::__throw_logic_error(), which goes to __cxa_throw, which goes to std::terminate(), which goes to (another function, probably the runtime, or a custom handler you might have implemented), which goes to __gnu_cxx::__verbose_terminate_handler(), which goes outside of the scope of the program to abort (libc), which goes to raise (libc), which goes to (some function) in the POSIX Thread shared library (v2.23), which goes to (some function) in the Mono runtime library (libmono), which goes back to abort, then raise, which causes the OS to terminate the program.

Had this program been compiled with debug symbols, I might have been able to tell you the name of the initial function in hook.x86_64 that causes the crash.

So unless there is some kind of option I can launch the game with that causes it to actually say what's causing it to throw a "logic error" and abort, this is about all the help I can give you.

Like, if the other games are also broken like this, I'm gonna have to refund it, and the other games, to avoid being stuck with a game that won't even launch.

[Braden]

Update: Here are the results for the other games:

Hook (this game): CRASHES (Aborted)

Zenge: CRASHES after unity config screen but before actual launch (Aborted)

Scalak: CRASHES, no "Aborted" message. Fails to load three plugins (ScreenSelector.so, libCsteamworks.so, libsteam_api.so)

Art of Gravity: CRASHES, no "Aborted" message, no message about failing to load a plugin

PUSH: CRASHES, no "Aborted" message, "Player data archive not found"

klocki: CRASHES, same as PUSH

[Braden]

Heads up: As I got all of these games (except klocki) in a bundle, refunding one would mean refunding all of them. And since we're talking about 5 games being broken and needing fixing in two days for an unknown startup bug, I'm gonna just refund them, because the sheer amount of fixing to be done is too much for two days. Implementation is in a managed language and the problem domain seems to breach a lower layer, meaning the fix is probably complicated. Plus, I don't even know if failing to launch is the ONLY problem these games have. For example: what if I hate them? What if they exhibit the unity fullscreen bug to such a horrible extent that I can't get them to play at all?

Let this be a lesson to properly test your games on a fresh installation on a non-developer system before you sell them. I won't leave a review, because I feel that would be unfair, as I haven't been able to actually experience the games. I hope this feedback helps you to be more diligent and improve your games in the future.

To help as much as I can, I will leave the valgrind tracebacks (if any) and statistics, of the other games in the next comment, just before I request the refunds.

Edit: Turns out I had a bit more than two days. I thought I'd bought the games earlier than I did. That doesn't affect my point, though. I wrote what I wrote because I didn't feel that any response + fix would come within the two week refund deadline. The continued lack of any response to this thread will only serve to further prove my point moving forward.

[Braden]

# Hook

==28410== Process terminating with default action of signal 6 (SIGABRT)
==28410==    at 0x64AC428: raise (raise.c:54)
==28410==    by 0x64AE029: abort (abort.c:89)
==28410==    by 0xB5638AE: ??? (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook_Data/Mono/x86_64/libmono.so)
==28410==    by 0x504F38F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.23.so)
==28410==    by 0x64AC427: raise (raise.c:54)
==28410==    by 0x64AE029: abort (abort.c:89)
==28410==    by 0x1321F6C: __gnu_cxx::__verbose_terminate_handler() (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)
==28410==    by 0x12E7E75: ??? (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)
==28410==    by 0x12E7EA2: std::terminate() (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)
==28410==    by 0x12E7A0D: __cxa_throw (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)
==28410==    by 0x13128BC: std::__throw_logic_error(char const*) (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)
==28410==    by 0xC7A789: ??? (in /home/braden/.local/share/Steam/steamapps/common/Hook/hook.x86_64)

Black window spawns for a fraction of a second before crash, 5MB in use at exit. Leaked 716 bytes in 6 blocks. 299 errors from 29 contexts

# Zenge

valgrind unable to run the game because it's 32-bit and my OS is 64-bit. Apparently the 32-bit version of ld-linux.so lacks the debug symbols needed to properly sandbox the program

Why does a game released in 2016 only have a 32-bit executable?

# Scalak

No traceback; it just terminates for no reason. Insane amount of references to uninitialized values. 35MB in use at exit. Leaked 3,317 bytes (3KB) in 21 blocks 829 errors from 243 contexts.

# Art of Gravity

No traceback; same as Scalak. Except a dark blue window spawns for a fraction of a second just before termination (valgrind severely slows down GUI programs). 30MB in use at exit. Leaked 5,723 bytes (6KB) in 15 blocks. 449 errors from 20 contexts.

# PUSH

No traceback; insane amount of references to uninitialized values. 30MB in use at exit. Leaked 3,773 bytes (4KB) in 21 blocks. 2,950 errors from 586 contexts.

# Klocki

No traceback; insane amount of references to uninitialized values. 31MB in use at exit. Leaked 3,257 bytes (3KB) in 18 blocks. 2,714 errors from 307 contexts.

# Summary

Scalak was the greediest with 35MB of memory in use at exit

Art of Gravity was the leakiest with 6KB of memory leaked

PUSH was the buggiest at nearly 3,000 memory errors.

[TheBlueInsurgent]

How about you just play on a normal OS, why would you think a linux is a good idea?? unless that is of course because of steam OS, cuz that is truly a fine OS.

[Braden]

Originally posted by TheBlueInsurgent:

How about you just play on a normal OS, why would you think a linux is a good idea?? unless that is of course because of steam OS, cuz that is truly a fine OS.

I AM playing on a "Normal" OS. Linux is perfectly normal.

why would you think a linux is a good idea??

Why would you think Windows is a good idea? The workflow, system design and organization are all inefficient and clunky, especially if you're a developer. Customization and software choice is basically nonexistent, and since it's proprietary and the license disallows reverse-engineering, tampering or disassembly, that means you can't even put on your dev hat to fix things to your liking. The only reason most people even have Windows is because it was bundled with their computer and they're too complacent, tech-illiterate or lazy to choose their own software. It's not because they like Windows. Though if you do, I won't judge. Just as long as you're cultured enough to recognize the nuances of the systems you're favoring Windows over.

Me, I've been using Linux as my main for six or seven years, and I don't plan to go back. Windows can stay in my side computer and my VM. Besides, I paid money for the game, so what kind of logic is "X claims to work with Y, but it doesn't. Therefore Y is stupid and you shouldn't use it."? Are you high?

Christ, you anti-Linux people are as annoying as anti-vim and anti-emacs people.

[Braden]

Anyways, I did end up fixing the problem. Problem with my NVIDIA hardware, needed a reboot.

[erparom]

game crashes, I won't elaborate, refunding