Native client might not run on some Linux distributions due to 32bit executable

[Cy]

I just tried the game after few years and native build doesn't start, at least on Manjaro. Changing launch command to:

%command% 1>&2 2>~/tmp/swh.log

gives the following error:

Fatal glibc error: malloc.c:2599 (sysmalloc): assertion failed: (old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)

Still works fine with Proton.

[Xena]

It runs for me out of the box. Debian 12, kernel 6x, up-to-date Nvidia drivers.
Could it be something related to this line "Fatal glibc error"?

[aradapilot]

This isn't a good solution, but try navigating to the game's directory (steamapps/common/...) in a terminal and running the game outside of steam. I've seen that malloc thing be something specific to the env setup when steam launches a 32 bit game...and I'm still looking for a solution to that, I want to know if your issue's the same

[Cy]

I get the same set of errors when running with Steam Linux Runtime 1.0 (scout).

When I try to run executable in game directory the first issue I get is lack of 32bit OpenAL library so I guess it should be bundled with the game:

❯ ./Heist
./Heist: error while loading shared libraries: libopenal.so.1: cannot open shared object file: No such file or directory
❯ ln -s /lib/libopenal.so.1
❯ ./Heist
./Heist: error while loading shared libraries: libopenal.so.1: wrong ELF class: ELFCLASS64

When I link a 32bit version from other game the executable actually calls Steam with steam://run/322190 as parameter, so the result is exactly the same set of errors as when just clicking PLAY in Steam:

❯ ln -s ~/.steam/steam/steamapps/common/Super\ Blood\ Hockey/lib/libopenal.so.1
❯ ./Heist
szCmd: /bin/sh -c '"/home/cg/.local/share/Steam/steam.sh" "steam://run/322190"' &

I finished the game so I don't care much, just wanted to share so that other people would know there might be issues with native build - it is a 32bit executable after all.

[Xena]

Originally posted by Cy:

it is a 32bit executable after all.

it's your system issue
my file links everything and seems to be OK

$ ldd Heist
	linux-gate.so.1 (0xf7f6a000)
	libsteam_api.so => ./libsteam_api.so (0xf7f2e000)
	libopenal.so.1 => /lib/i386-linux-gnu/libopenal.so.1 (0xf7e15000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7e10000)
	libGL.so.1 => /lib/i386-linux-gnu/libGL.so.1 (0xf7da4000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7d9f000)
	libstdc++.so.6 => /lib/i386-linux-gnu/libstdc++.so.6 (0xf7a00000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7c9a000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7c73000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7600000)
	/lib/ld-linux.so.2 (0xf7f6c000)
	libsndio.so.7.0 => /lib/i386-linux-gnu/libsndio.so.7.0 (0xf7c5d000)
	libGLdispatch.so.0 => /lib/i386-linux-gnu/libGLdispatch.so.0 (0xf7984000)
	libGLX.so.0 => /lib/i386-linux-gnu/libGLX.so.0 (0xf7c21000)
	libasound.so.2 => /lib/i386-linux-gnu/libasound.so.2 (0xf785f000)
	libbsd.so.0 => /lib/i386-linux-gnu/libbsd.so.0 (0xf7848000)
	libX11.so.6 => /lib/i386-linux-gnu/libX11.so.6 (0xf74ae000)
	libmd.so.0 => /lib/i386-linux-gnu/libmd.so.0 (0xf7839000)
	libxcb.so.1 => /lib/i386-linux-gnu/libxcb.so.1 (0xf7480000)
	libXau.so.6 => /lib/i386-linux-gnu/libXau.so.6 (0xf7834000)
	libXdmcp.so.6 => /lib/i386-linux-gnu/libXdmcp.so.6 (0xf782d000)

$ whereis libopenal.so.1
libopenal.so.1: /usr/lib/x86_64-linux-gnu/libopenal.so.1

$ file /usr/lib/x86_64-linux-gnu/libopenal.so.1
/usr/lib/x86_64-linux-gnu/libopenal.so.1: symbolic link to libopenal.so.1.19.1

$ whereis libopenal.so.1.19.1
libopenal.so.1.19.1: /usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1

$ file /usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1
/usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=4e101dc88ba6c2f6327724a4e2582a0cc4b68f57, stripped

what's your ldd output? it will show which libs you're missing and that can be the answer. as you can see from last output of file the lib is 64 bit. you just have to install/manage openAL

[Cy]

Originally posted by Xena:

Originally posted by Cy:

it is a 32bit executable after all.

it's your system issue
my file links everything and seems to be OK

My file links everything as well, it just expects the system I'm on to have a 32 bit OpenAL available, which it doesn't have and honestly I don't think any Linux distribution has it nowadays (not counting Ubuntu) unless you explicitly install it. Your system has both - 32 and 64 bit versions available. I already worked around it by linking 32 bit OpenAL library from another game that packaged it. It didn't solve the malloc issue.

To satisfy your curiosity:

❯ ldd Heist
        linux-gate.so.1 (0xe9277000)
        libsteam_api.so => ./libsteam_api.so (0xe923b000)
        libopenal.so.1 => not found
        libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xe91fa000)
        libGL.so.1 => /usr/lib32/libGL.so.1 (0xe918f000)
        libdl.so.2 => /usr/lib32/libdl.so.2 (0xe918a000)
        libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xe8f14000)
        libm.so.6 => /usr/lib32/libm.so.6 (0xe8e40000)
        libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xe8e0c000)
        libc.so.6 => /usr/lib32/libc.so.6 (0xe8bdd000)
        /lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xe9279000)
        libGLdispatch.so.0 => /usr/lib32/libGLdispatch.so.0 (0xe8b5f000)
        libGLX.so.0 => /usr/lib32/libGLX.so.0 (0xe8b24000)
        libX11.so.6 => /usr/lib32/libX11.so.6 (0xe89d3000)
        libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xe89a6000)
        libXau.so.6 => /usr/lib32/libXau.so.6 (0xe89a1000)
        libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xe899a000)

❯ whereis libopenal.so.1
libopenal.so.1: /usr/lib/libopenal.so.1

❯ file /usr/lib/libopenal.so.1
/usr/lib/libopenal.so.1: symbolic link to libopenal.so.1.23.1

❯ whereis libopenal.so.1.23.1
libopenal.so.1.23.1: /usr/lib/libopenal.so.1.23.1

❯ file /usr/lib/libopenal.so.1.23.1
/usr/lib/libopenal.so.1.23.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=69cede7515174c25fdcb6c51bbb291ca35c0ef6a, stripped

[Xena]

now, that's what happens if you do not enable multiarch before installing video drivers and steam. you will have only 64bit version installed.
I did multiarch and steam pulled all 32bit libs it needed, I don't believe I had to install any of it manually. all my libs go paired 64/32 so I probably had to ask first if you have multiarch enabled.

I have no idea what are steam dependencies now for arch based distros, but judging by this page it is still a thing? steam-native-runtime still depends on it?
https://archlinux.org/packages/multilib/x86_64/lib32-openal/

if anyone reading this also had issues with 32libs missing uninstall steam, enable multiarch (debian based) or multilib (arch based), install steam and it should pull all required libraries.

https://wiki.debian.org/Multiarch/HOWTO
https://wiki.archlinux.org/title/Official_repositories

[Cy]

Originally posted by Xena:

now, that's what happens if you do not enable multiarch before installing video drivers and steam. [...]

I'm marking this as an answer because it might solve an OpenAL issue for some folks but as I said before, that's not the reason the game didn't start. I had multilib repo enabled since 2016 and never manually removed any libs from it. I also checked logs back to 2018 and they never mention 32 bit version of OpenAL getting installed or uninstalled - I'm guessing it never got installed in the 1st place and yet the game worked for me natively back in 2019. So thanks for your help, have your response marked, but that's a non-issue - malloc problem happens even with 32 bit OpenAL preloaded.