Every article tag can be clicked to get a list of all articles in that category. Every article tag also has an RSS feed! You can customize an RSS feed too!
We do often include affiliate links to earn us some pennies. See more here.

Steam Game Recording was recently released, which came as part of a big Stable Steam Client update that noted it had fixes for "miscellaneous common crashes" on Linux. Now we know a little more on what's happening behind the scenes.

Coming from a blog post from developer Timothée Besset, who does a lot of Valve work, Besset mentions how a change to how they approach the setenv and getenv functions that made the "most significant impact to Steam client stability on Linux".

For some context:

  • setenv: change or add an environment variable.
  • getenv: get an environment variable.

According to Besset, one of their colleagues claimed setenv as "the worst Linux API", even though it's such a common API available across all platforms "it was a little difficult to convince ourselves just how bad it is" — ouch. And they already knew, at least on Linux, that "setenv and getenv aren't safe to use in multithreaded environments".


Pictured - Steam Client

Part of their problem though is how on Linux you have so many distributions with different window managers, desktop environments, driver versions, extensive user customization and so on. So their own crash reports end up "very noisy". Another issue is that setenv will at times in a multithreaded program "crash outright", on top of that they found that "other threads would blow up though, usually with a SIGABRT, shortly after calling getenv", and their backtraces for the crashes were "all over the place and could not be easily tied to a single cause".

So what did they do? Here's what:

  • We removed the majority of setenv calls. It was mostly used when spawning processes, and refactoring to use exevpe to pass down a prepared environment is an all around improvement.
  • We reduced how much we rely on getenv, mostly by caching the calls. There is still an uncomfortable amount of it, but it's in OS libraries at this point (x11, xcb, dbus etc.) and we continue reducing it's usage.
  • For the few remaining setenv use cases that could not be easily refactored, we introduced an 'environment manager' that pre-allocates large enough value buffers at startup for fixed environment variable names, before any threading has started.

It's a fun little read worth a couple minutes of your time if you're interested on behind the scenes info, and how at times building for Linux can be a minefield.

According to a comment on the post, these issues are in fact being worked on in glibc, so it may not be such a problem in future for Linux developers.

The more stable it is, the better the experience will be for people switching to Linux, and of course for the Steam Deck too since SteamOS is Linux. Nice to see Valve developers constantly trying to make everything better.

Article taken from GamingOnLinux.com.
Tags: Misc, Steam, Valve
28 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
14 comments
Page: «2/2
  Go to:

WMan22 Nov 13
My wishlist for things I would love if Steam changed on their linux client:

- Drag and drop support for steam chat when it comes to pictures and videos from your file manager like dolphin, nautilus, nemo, etc. please, oh my god that is straight up one of the only remaining areas where I think linux is an objective downgrade from windows. Discord clients on linux can do it and they can't even stream with audio; Why can't steam have drag and drop file support?
- Store/Community webpage black screen bug until you click library and go back is fixed.
- You can pick and choose which games get shader pre-caching and which don't instead of checking it for every game or no game. It is a straight up detriment to games like Warframe which have to download 10GB of shaders basically every single time I boot up my PC only to have new assets stutter anyway, and takes like 6 hours to actually compile the vulkan shaders for that game on steam. Other games though don't have this issue and benefit from fossilize.
- Media codec fixed versions of videos in proton are decoupled from fossilize's shader cache as a separate setting.
- Fix Big Picture mode running like ass on Nvidia Wayland with and without hardware acceleration
- Gamescope-session (Steam deck's "Gaming Mode") becomes as normalized on Nvidia as much as it is on AMD.
- 64 bit client


Last edited by WMan22 on 13 November 2024 at 9:39 am UTC
Quoting: CatKiller
Quoting: Vortex_AcheronticYet I am surprised it works in flatpak at all. Especially the Steam Runtimes which kinda are their own flatpaks inside flatpak.
It didn't work, specifically because of that issue with nested bubblewrap. They made changes to both the Steam client and flatpak so that the client can negotiate to run things with flatpak's bubblewrap. And now it works.

Yes I am pretty much aware of this. I've read the news too back then which is why I phrased it like that.

Still it works now and it is still surprising it does so well. However I still feel like the Steam Client needs a lot of refactor to properly integrate with the Linux desktop as it is today.

Still no 64bit, no native Wayland support, broadcasting is still bugged, Big Picture Mode still lags on nvidia hardware and I feel like for the Deck they need to entirely reinvent the store page because the current state, trying to force the webpage on deck and somehow try to navigate with a controller is super uncomfortable to use.

Sometimes also buggy in a way that the selection indicator is somewhere off screen or in the wrong layer and controls something in the background. Sometimes the toolbar which shows the buttons to press is flashing on the store page. There are still after so many years so many little annoying buggy things which definitely need a lot of rework to the underlying client if not an entire rewrite of the software. In the end this could benefit a proper flatpak integration too.


Last edited by Vortex_Acherontic on 14 November 2024 at 12:42 am UTC
dvd Nov 17
Quoting: Marlock
Quoting: ElectricPrism
Quoting: hummer010I'd just like to see Valve move into the 2010's and make the Steam client 64-bit.

I'll second that. I think Steam is probably the only thing keeping 32-bit multilib around for me. It would be nice to see it go for organization and cleanliness.
If the steam client moves entirely to 64-bit, they'll still need 32-bit libs to run old 32-bit games.

Wine/Proton may be able to use 64-bit libs for 32-bit windows games (not yet but working on it afaik). And then there are native linux games, where it's a bit trickier, though most linux native games are 64-bit iirc.

They could just use a light container and run those games with that. These are old software, so probably one container would suffice. There are tons of them, and they do not slow games down or dictate the user to enable a foreign distribution channel like flatpak does.
Kelly about 4 hours ago
  • New User
When is the linux PC steam app going to stop causing issues with playing games, like Final Fantasy 14, for more than 30 minute at a time before the graphics start bouncing around like a fiddler's elbow? It's like slowly going through an old flip book when moving, and I have to exit the game and relaunch. Sometimes I have to exit the steam app too.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.