What I expected to happen: Steam client produces no significant error messages
What actually happens: Every time I run the Steam client I get the message Assertion Failed: ERROR: unsafe call to setenv count:1 var:'PATH' /data/src/common/linux_setenvwrapper.h:74 on stderr, with a corresponding dump file in /tmp/dumps.
This failure does NOT prevent the rest of the client from starting and running, but it's clearly indicating a misuse of the setenv/getenv API, and could be a background cause of other problems (e.g. memory corruption if one thread is holding a pointer returned from getenv() that was invalidated by another thread's subsequent setenv(), or issues in other processes if environment variable updates are not being passed along as intended).
As noted in the setenv(3) manpage, "CAVEATS: POSIX.1 does not require setenv() or unsetenv() to be reentrant," so calls to these functions should be either definitively confined to a single thread or protected by a mutex. In other words, the assertion is properly calling attention to a potential race condition. You can find a more elaborate discussion of the problem at https://www.evanjones.ca/setenv-is-not-thread-safe.html.
A GDB trace shows that setenv() is called seven times during the Steam client startup on my system. I don't have debugging symbols in my Steam client binary so I was unable to easily generate a useful backtrace.
Steps to reproduce:
Invoke the Steam client through the normal /usr/bin/steam wrapper script
System information:
What I expected to happen: Steam client produces no significant error messages
What actually happens: Every time I run the Steam client I get the message
Assertion Failed: ERROR: unsafe call to setenv count:1 var:'PATH' /data/src/common/linux_setenvwrapper.h:74on stderr, with a corresponding dump file in/tmp/dumps.This failure does NOT prevent the rest of the client from starting and running, but it's clearly indicating a misuse of the setenv/getenv API, and could be a background cause of other problems (e.g. memory corruption if one thread is holding a pointer returned from
getenv()that was invalidated by another thread's subsequentsetenv(), or issues in other processes if environment variable updates are not being passed along as intended).As noted in the
setenv(3)manpage, "CAVEATS: POSIX.1 does not require setenv() or unsetenv() to be reentrant," so calls to these functions should be either definitively confined to a single thread or protected by a mutex. In other words, the assertion is properly calling attention to a potential race condition. You can find a more elaborate discussion of the problem at https://www.evanjones.ca/setenv-is-not-thread-safe.html.A GDB trace shows that
setenv()is called seven times during the Steam client startup on my system. I don't have debugging symbols in my Steam client binary so I was unable to easily generate a useful backtrace.Steps to reproduce:
/usr/bin/steamwrapper scriptsteam-logs.tar.gz