You are not logged in.
The Steam client crashes with a segmentation fault when attempting to run "STEAM_RUNTIME=0 steam".
This wouldn't be so much of an issue if disabling the runtime wasn't required by SimpleScreenRecorder to inject it's libraries into steam games.
I've run steam through gdb with runtime disabled, here are a few errors that stand out:
/home/buildbot/buildslave_steam/steam_rel_client_ubuntu12_linux/build/src/vgui2/src/../vgui_surfacelib/FontManager.cpp (276) : Assertion Failed: descs.Count() >= 1
/home/buildbot/buildslave_steam/steam_rel_client_ubuntu12_linux/build/src/vgui2/src/../vgui_surfacelib/FontManager.cpp 276 Assertion Failed: descs.Count() >= 1
Program received signal SIGTRAP, Trace/breakpoint trap.
0xf4ccfd87 in AssertMsgImplementation ()
from /home/bigstiffy/.local/share/Steam/ubuntu12_32/libtier0_s.so
Program received signal SIGSEGV, Segmentation fault.
0xf7bfae86 in __strlen_sse2_bsf () from /usr/lib32/libc.so.6
Requested Force create but SharedObjectMutex already created
Forced create but already created for SharedObjectEvent
Forced create but already created for SharedObjectEventAfter a few hours of looking for answers, it seems that Steam requires an older version of lib32-glibc than what is currently installed,
although continues to functions so long as runtime is enabled by default. Running steam with default settings through gdb showed no
errors regarding either "libtier0_s.so" or "libc.so.6".
Is there a way to obtain an older package of lib32-glibc from the repo to test if this is the culprit?
Building and compiling glibc from source is just a little bit outside my realm of understanding.
Last edited by bigstiffy (2015-04-18 02:02:27)
Offline
Is there a way to obtain an older package of lib32-glibc from the repo to test if this is the culprit?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
^ You sure rollbacking libc is a great idea? ![]()
What Steam on Arch really wants is an Ubuntu chroot.
Last edited by Alad (2015-01-07 17:15:07)
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
I'll give that a shot and see if Steam decides to function with runtime disabled.
^ You sure rollbacking libc is a great idea? yikes
What Steam on Arch really wants is an Ubuntu chroot.
I am never sure of anything.
Although, I'm pretty sure Steam has it's chroot, as it runs with runtime automatically enabled.
The recent error I get when debugging it I can only assume is do to a recent update to glibc, since Steam itself
would rely on an older version.
Offline
Also following some information from another thread, I ran
STEAM_RUNTIME=0 strace -o tmp steam; head tmpAnd got this output:
execve("/usr/bin/steam", ["steam"], [/* 32 vars */]) = 0
brk(0) = 0x1c89000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=242411, ...}) = 0
mmap(NULL, 242411, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb6211bb000
close(3) = 0
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\1\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1984416, ...}) = 0So the Steam client is looking for ld.so.preload where it doesn't exist, and accessing the 64bit glibc library.
I think that when Steam runs with runtime disabled, it is supposed to use the 32bit libraries, but it doesn't search
in /usr/lib32 when the runtime is disabled. I rolled back lib32-glibc to 2.20-2 (Dec 1st, 04) and there was no change.
Any ideas?
Offline
What about creating the directory it is looking for and putting a copy of the file/s there.
Last edited by grndzro (2015-01-25 08:29:13)
Offline
What about creating the directory it is looking for and putting a copy of the file/s there.
Well, I don't know if there is a "ld.so.preload" file anywhere, but I don't think it's really the root of problem.
I've attempted a stack trace again after steam had updated recently, steam is no longer searching in /usr/lib where the 64bit libraries are,
but it seems it is still not satisfied with the existing libc file, so I guess it still requires a much older version of glibc.
Continues to function as normal when using it's own packaged libraries.
Official Steam support has been lackluster as far as helpfulness goes, their first 3 response seemed automated, telling me to try
the same solution each time (to run "steam --reset"). Last response recommended renaming the steamapps folder and reinstalling a game
which does not seem in any way related to the problem.
Offline
Solved my issue!
Prior to my problem, I had been using the "steam-libs" package from [alucryd-multilib] as recommended by the arch wiki for running Steam on native libraries.
The solution:
I had to completely remove the "steam-libs" package, and install "steam-native" from AUR.
Steam is now able to run on native libraries, but still does not properly set the LD_LIBRARY_PATH variable, so this command is needed to run it without the steam runtime:
$ LD_LIBRARY_PATH=/usr/lib32 env STEAM_RUNTIME=0 steam %UI did experience a steam game hanging which prevented steam from exiting at first, but the problem has not occurred since, so I'll consider it a fluke.
Offline
Probably contact Alucryd (if he hasn't already seen this thread). steam-native is an abysmal cludge that I wouldn't wish on my worst enemy.
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline