Skip to main content

Improving Steam Client stability on Linux: setenv and multithreaded environments

Speaking of Steam, the Linux version of Valve's gaming platform has just received a pretty substantial set of fixes for crashes, and Timothee "TTimo" Besset, who works for Valve on Linux support, has published a blog post with more details about what kind of crashes they've been

osnews.com/story/141109/improv…

#Linux

Improving Steam Client stability on Linux: setenv and multithreaded environments – OSnews

www.osnews.com
#linux
in reply to OSNews

Gabriele Svelto
Gabriele Svelto
• •

I fixed - not mitigated - this issue in Firefox for good some time back. I had written a short thread about it: fosstodon.org/@gabrielesvelto/…

Bug and patches are here: bugzilla.mozilla.org/show_bug.…

Long story short: I use *linker magic* to slot thread-safe functions between the code using them and the non-thread-safe implementations in glibc. This way even code we don't control is forced to acquire a lock before manipulating the environment, entirely preventing races.

1752703 - Crash in [@ __GI_getenv]

RESOLVED (gsvelto) in Core - Graphics. Last updated 2024-01-11.
bugzilla.mozilla.org

Gabriele Svelto

2023-05-09 10:17:05


In today's #Firefox bugs that require some thought. getenv() / setenv() aren't thread-safe but a bunch of libraries use them anyway. Boom.

We have to fix that but we can't change the libraries. How do we do it? By abusing the linking order and slotting our own thread-safe getenv() before libc's one.

So far so good.

Except that on older versions of Android we use our own linker to work around issues in the system one. And our linker wants to call getenv() too. Boom again.


in reply to Gabriele Svelto

Gabriele Svelto
Gabriele Svelto
• •
it's ridiculous we have to jump through these kind of hoops but that's what happens when your APIs have been designed some 50 years ago and people keep using them because there's no alternatives.
⇧