- Nov 02, 2023
-
-
Simon McVittie authored
Historically we completely ignored errors here, so it's possible that there are valid scenarios where this fails; just log a warning instead of stopping the whole runtime setup. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
No changes that need to be listed here. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
glib-backports: Provide G_SOURCE_FUNC See merge request !624
-
Ludovico de Nittis authored
utils: Don't reset SIGBUS, SIGFPE, SIGSEGV handlers under AddressSanitizer See merge request !622
-
Simon McVittie authored
This avoids gcc warnings by making use of the fact that gcc allows casts of any function pointer to/from a function with no result and no arguments, which both gcc and GLib use as a stand-in for a function with unspecified result and unspecified arguments. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
AddressSanitizer sets handlers for these signals to provide better diagnostics. Fixes: 52e494e5 "utils: Unignore all signals, not just the ones Steam historically altered" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
architecture: Remove an unused variable See merge request !623
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 01, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
CLI tools: unblock and unignore signals during startup See merge request !619
-
- Oct 30, 2023
-
-
Simon McVittie authored
This avoids some duplication. It does mean that we can't check for failures, but it's not as if we can really do anything useful about any error from pthread_sigmask() anyway. The only errors documented for pthread_sigmask() are EFAULT (a programming error) and EINVAL (either a programming error, or use of a signal-set size not supported by the kernel). If we were going to get EINVAL, we would also have had the same error during program startup, when we called _srt_unblock_signals(), which *does* report errors. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Unlike most POSIX functions, instead of returning -1 and setting errno on error, pthread_sigmask() returns a positive errno-like value on error. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 26, 2023
-
-
Simon McVittie authored
To get from an unknown execution environment into a known state, it's more robust if we reset all signals, not just a few. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
When our executables get run via execve(), any custom signal handlers get reset to SIG_DFL by the kernel: nothing else would make sense, because the pointer to a custom signal handler would no longer be valid in the new executable's address space. As a result, we start up with all signals set to either SIG_IGN or SIG_DFL. _srt_unblock_signals() is meant to be called sufficiently early that it will not reset any custom signal handlers, because there should not yet be any. Log a warning if that assumption is broken. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As with s-r-launcher-service, Steam or a game could run these tools in an arbitrary environment, with necessary signals either blocked (sigprocmask() or similar), or ignored (sigaction() with action SIG_IGN, or similar). Both of these are inherited across fork() and execve() by default. s-r-system-info and s-r-check-compatibility do not need this change: they already called _srt_unblock_signals(), which unblocks all signals, and unignores selected signals that have been a practical problem in the past. pv-try-setlocale does not need this change: in practice it only gets run by pv-adverb, so it inherits pv-adverb's fix for this. helpers/ do not need this change: they get called with _srt_child_setup_unblock_signals() and inherit its fix for this. tests/ do not need this change: Meson should run them in a sensible environment. steamrt/tasks#354 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Move non-PV-specific tests outside tests/pressure-vessel/ See merge request !620
-
- Oct 25, 2023
-
-
Simon McVittie authored
Only launcher.py actually needed this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It doesn't actually have anything to do with pressure-vessel any more. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
There's nothing pressure-vessel-specific about it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Just for completeness, really. Previously we didn't test this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Without this, running the test in a soldier container, launched from a host with (for example) LC_ADDRESS=en_GB.utf8, will fail. Until now, this was masked by the fact that this test was unnecessarily skipped when dbus-run-session is unavailable, but I want to change that. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 24, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
steam-runtime-tools v0.20231013.1 * launcher-service: Unblock and unignore all signals during startup, fixing detection of subprocesses exiting when launched by Steam (steamrt/tasks#354, ValveSoftware/SteamVR-for-Linux#618)
-
Simon McVittie authored
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Steam could run this tool in an arbitrary environment, with necessary signals either blocked (sigprocmask() or similar), or ignored (sigaction() with action SIG_IGN, or similar). Both of these are inherited across fork() and execve() by default, and current versions of Steam do block SIGCHLD in practice. However, blocking or ignoring SIGCHLD breaks handling of subprocesses, which is particularly critical for s-r-launcher-service: that prevents it from detecting that its child processes have exited, causing s-r-launch-client to hang forever, which in turn breaks startup of SteamVR on systems where /bin/sh is dash (but not bash, which apparently resets the disposition of SIGCHLD internally). steamrt/tasks#354, https://github.com/ValveSoftware/SteamVR-for-Linux/issues/618 Signed-off-by:
Simon McVittie <smcv@collabora.com> (cherry picked from commit d2bd4e4b)
-
Simon McVittie authored
urlopen: Use steam://openurl_external to open http, https URLs See merge request !618
-
Simon McVittie authored
Steam could run this tool in an arbitrary environment, with necessary signals either blocked (sigprocmask() or similar), or ignored (sigaction() with action SIG_IGN, or similar). Both of these are inherited across fork() and execve() by default, and current versions of Steam do block SIGCHLD in practice. However, blocking or ignoring SIGCHLD breaks handling of subprocesses, which is particularly critical for s-r-launcher-service: that prevents it from detecting that its child processes have exited, causing s-r-launch-client to hang forever, which in turn breaks startup of SteamVR on systems where /bin/sh is dash (but not bash, which apparently resets the disposition of SIGCHLD internally). steamrt/tasks#354, https://github.com/ValveSoftware/SteamVR-for-Linux/issues/618 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Use SrtSysroot in pv-runtime See merge request !616
-
Simon McVittie authored
Convert its test coverage into test coverage for _srt_sysroot_test(), rather than wasting it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the libdir isn't a directory, then we certainly don't need to (and can't) delete its contents. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
No functional change, the mutable sysroot is always accessed via fd-based I/O anyway; but the resulting code is a bit shorter. Several direct uses of _srt_resolve_in_sysroot() remain, because they use SRT_RESOLVE_FLAGS_MKDIR_P, but that's fine. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As with earlier commits, this will usually have no practical effect, but it will make explicit --graphics-provider=/ more likely to work under FEX-Emu. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
No functional change, because self->host_root is always fd-based I/O anyway. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This means that if the provider is the current execution environment, we will use path-based rather than fd-based I/O. That should not have any practical effect, because when we're running under FEX-Emu, the graphics provider defaults to the FEX rootfs anyway, and when we are not being emulated, there's no practical difference between path-based and fd-based I/O; but it could matter for non-FEX emulators, and will make explicit --graphics-provider=/ work better under FEX. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
No functional change: self->host_root is never using direct I/O anyway. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-