- Feb 13, 2025
-
-
Simon McVittie authored
LD_PRELOAD modules are an inherently fragile mechanism, and any symbols exported by either a LD_PRELOAD module or its direct dependencies will "interpose" in front of symbols of the same name from any other library. In some cases this can lead to crashes, for example when the Python ctypes module from Steam Runtime 2 'soldier' (which depends on libffi.so.6) gets its libffi references resolved to symbols from a more modern host system's libffi.so.7 or libffi.so.8 pulled in by the dependency chain: libMangoHud.so -> libwayland-client.so.0 -> libffi.so.8 Authors of LD_PRELOAD modules like MangoHud can avoid this situation by making their LD_PRELOAD module only depend on highly long-term-stable projects (ideally only glibc), and then loading the implementation of its real functionality via `dlopen()`, using `RTLD_LOCAL|RTLD_DEEPBIND` to avoid symbol conflicts. For example, newer versions of MangoHud separate the module into libMangoHud_shim.so (the actual LD_PRELOAD module, no dependencies except glibc) and libMangoHud_opengl.so (dlopen'd by the shim module, depends on whatever it needs to depend on). This is a good approach and we should encourage it, but in the current pressure-vessel codebase it isn't going to be completely reliable for modules that are installed other than in /usr: for libMangoHud_shim.so to be able to load libMangoHud_opengl.so, we need to ensure that they are both visible in the filesystem of the game's container. However, since we can't know what modules and/or libraries libMangoHud_shim.so is going to load at runtime, we will have to use a heuristic. The heuristic I've chosen here is to say that if you have `LD_PRELOAD=/path/to/some/module.so`, then instead of sharing `/path/to/some/module.so` with the container as we did previously, we should share the parent directory `/path/to/some/`. In particular, this is enough for MangoHud's requirements. However, one notable exception is that if the module is situated directly inside `$HOME`, and we are using `--unshare-home` to avoid sharing the home directory with the container, we probably do not want to overrule that. In this case, users will still need to use `PRESSURE_VESSEL_FILESYSTEMS_RO` to share the dependency explicitly. steamrt/tasks#595 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Contrast this with the previous test coverage for a module directly inside $HOME: in that situation we don't want to overrule --unshare-home, but in this situation we do want to share a small subset of it. steamrt/tasks#595 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In two cases we were asserting that the grandparent directory is not exported, and the LD_PRELOAD module itself is, but making no assertion about the parent directory of the LD_PRELOAD module. To make modules like MangoHud work more reliably, in fact we want to export the parent directory in most cases. steamrt/tasks#595 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
steamrt/tasks#595 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This keeps the inputs and their expected results together. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Otherwise, we can't test behaviours that depend on the home directory. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes no sense: the comment above indicates that we *didn't* want this path to be exported, and if it was exported then we would be unable to have any control over the filesystem namespace. In fact, it is not exported: the fact that it appears to be exported is an implementation quirk of flatpak_exports_path_get_mode(), which returns FLATPAK_FILESYSTEM_MODE_READ_WRITE because none of the zero remaining path segments is unmapped. 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
This will let us make the tests that involve it more declarative, by grouping the various inputs and expectations related to one LD_PRELOAD entry into the struct associated with that entry. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will make it clearer when writing tests where a LD_PRELOAD entry is very similar (or even identical) to the path that we need to create to represent it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
No functional change. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 12, 2025
-
-
Simon McVittie authored
This will allow the LD_PRELOAD handling code to use a real or mock home directory, as appropriate. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
!784 was adequately documented as "Refactoring" already. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
pv-wrap: Store more state in the PvWrapContext See merge request !784
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This can be used to set a mock home directory for unit testing, which we now do in the wrap-setup test (although it isn't used for anything yet). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This means we don't have to thread it through so much of wrap-setup as an explicit function parameter. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It's slightly simpler without duplicating 1 bit of information like this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This lets us pass it to various functions as one parameter rather than two. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This keeps more of the things we have to mock for unit testing together, avoiding needing to thread a copy of the environment through the LD_PRELOAD setup code. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes the tests a little bit closer to reality. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We're just looking at this, not altering it (not that we would be able to alter it with correct memory management under this calling convention, but that isn't necessarily immediately obvious to a reader). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes no practical difference yet, but we can use this for more consistent handling of a mock root directory for unit-testing in future. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
launch-options: More options for SDL See merge request !786
-
Simon McVittie authored
Further refactoring towards steamrt/tasks#595 See merge request !783
-
Simon McVittie authored
systemd sets this variable for units with `RestartMode=debug` if a previous attempt at starting the unit failed, and projects like GLib and pressure-vessel are starting to use it as a general-purpose opt-in to extra debug information. I suggested in https://github.com/libsdl-org/SDL/issues/12275 that SDL could maybe do the same. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
By default, we will use a bundled copy of SDL 2 or SDL 3 if a game happens to provide one: for example, Hitman (2016) has a bundled copy of SDL 2.0.5, and Dota 2 has a bundled copy of some intermediate version between 3.1.6 and 3.1.8 at the time of writing. When using pressure-vessel, we can override that with the Steam Runtime's newer, presumably-better version (steamrt/tasks#578). For SDL 2, in runtime versions that contain sdl2-compat as a non-default version, we can do the same to replace classic SDL 2 with sdl2-compat (steamrt/tasks#579). Expose this in steam-runtime-launch-options to make it more discoverable and easier to test. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
SDL 2 uses SDL_VIDEODRIVER, SDL 3 prefers SDL_VIDEO_DRIVER. Having individual control over the two libraries doesn't seem worth the extra space taken up in the UI, so set both from the same combo box. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 07, 2025
-
-
Simon McVittie authored
No functional change. Best reviewed with `git show --ignore-space-change`. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This means all the parsing and serialization is in one place, and we can round-trip between the struct representation and the command-line option representation. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will help us to centralize the code that maps to/from pv-adverb command-line options. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Convert to a concrete pv-adverb option name at the last possible moment. This will help us to centralize the code to map to/from pv-adverb command-line options. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This allows it to have test coverage. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 06, 2025
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
pressure-vessel: Add STEAM_COMPAT_RUNTIME_SDL2=sdl2-compat See merge request !782
-
- Feb 04, 2025
-
-
Simon McVittie authored
After we add sdl2-compat to container runtimes, we will presumably want a reasonably long testing period in which the default is still "classic" SDL2, but users, developers and testers can opt-in to using sdl2-compat as a replacement for it. This mechanism lets us achieve that. This will not be practically useful until soldier and/or sniper includes a copy of sdl2-compat. steamrt/tasks#579, steamrt/tasks#573 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-