Skip to content
Snippets Groups Projects
  1. Oct 28, 2022
  2. Jun 21, 2022
  3. Apr 07, 2022
  4. Mar 31, 2022
  5. Jan 27, 2022
  6. Sep 20, 2021
    • Simon McVittie's avatar
      Avoid misleadingly-named g_spawn_check_exit_status() if possible · c507a0a2
      Simon McVittie authored
      
      g_spawn_check_exit_status() was renamed to g_spawn_check_wait_status()
      in GLib 2.70 because its name was misleading: the first argument was
      always a wait-status (the output of wait(), waitpid() or waitid(),
      encoding either an exit status or a terminating signal) rather than an
      exit status.
      
      Use the modern name in our code. When building for scout or
      continue to provide our own implementation; when building for anything
      else older than GLib 2.70, provide a macro to wrap the old, misleading
      name.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      c507a0a2
  7. Aug 06, 2021
  8. Aug 03, 2021
  9. Jul 20, 2021
    • Ludovico de Nittis's avatar
      Adjust LD_PRELOAD and LD_AUDIT to prevent ELF warnings · e7a5f274
      Ludovico de Nittis authored and Simon McVittie's avatar Simon McVittie committed
      
      When a game is launched with the Steam Overlay feature enabled (it's on
      by default), we end up with an LD_PRELOAD that contains
      `gameoverlayrenderer.so` two times, one for 32-bit and the other for
      64-bit processes.
      
      However this leads to a warning that is harmless but scary for users and
      developers unaware of that:
      `ERROR: ld.so: object
      '/home/me/.local/share/steam/ubuntu12_64/gameoverlayrenderer.so' from
      LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.`
      
      And every 64-bit process prints something similar about the ELFCLASS32.
      
      By creating a temporary directory and using the dynamic linker token
      expansion `$PLATFORM` we can let a process preload only the
      `gameoverlayrenderer.so` for the right ABI.
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      e7a5f274
  10. May 20, 2021
  11. May 12, 2021
  12. Apr 22, 2021
  13. Feb 26, 2021
    • Simon McVittie's avatar
      pressure-vessel: Put apt-style severity prefixes on messages · dbf21961
      Simon McVittie authored
      
      These indicate which lines are harmless and which lines are really bad,
      without taking up too much space.
      
      The mapping from GLib log level to message is not 100% obvious, because
      G_LOG_LEVEL_ERROR is "worse than" an error. We diagnose "can't happen"
      situations (assertion failures, etc.) as "Internal error". Ideally,
      users should never see these: they indicate a bug.
      
      For situations that will cause pressure-vessel to exit with an error,
      introduce a new log level flag PV_LOG_LEVEL_FAILURE and map it to the
      apt-style "E:" prefix. pv_log_failure() is a convenience macro to log
      at level PV_LOG_LEVEL_FAILURE. Conceptually this is a fatal error, but
      it's a fatal error prompted by something external to pressure-vessel,
      for which we want pressure-vessel to clean up "nicely" and exit
      gracefully, even though it's going to fail - so we can't use g_error()
      for this.
      
      In the parts of main() that involve parsing command-line arguments,
      add usage_error() as syntactic sugar for pv_log_failure(). I might
      eventually turn these into G_OPTION_ERROR_FAILED as we factor out
      more of main() into helper functions, but for now they're handled
      separately.
      
      For less-severe log levels, use single-letter prefixes similar to apt's.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      dbf21961
  14. Feb 25, 2021
  15. Feb 23, 2021
  16. Jan 13, 2021
  17. Jan 05, 2021
  18. Dec 17, 2020
    • Simon McVittie's avatar
      pressure-vessel: Let short-term subprocesses inherit non-CLOEXEC fds · 97b5a8f6
      Simon McVittie authored
      To work around older versions of GLib having a potential deadlock in
      their fd-closing code due to use of non-async-signal-safe functions
      in the forked child process, the Flatpak-derived code we're using here
      uses a simple, naive implementation of closing fds: it iterates through
      every possible fd, up to the rlimit.
      
      Unfortunately, Wine users sometimes set their fd rlimit very high
      (typically around a million), because the "esync" mechanism in Proton's
      Wine needs a lot of fds. The time taken by each individual syscall is
      not significant, but when we do a million of them, it adds up. This
      is arguably a misconfiguration - the recommendation is now to have a
      soft rlimit of 1024 and a hard rlimit of about a million, so that
      only processes that opt-in to dealing with a million fds have to be
      aware of them - but a significant number of misconfigured systems
      probably still exist.
      
      We don't actually *need* to close all the fds here: there's no security
      boundary, so giving the child access to unnecessary fds isn't a
      privilage gain; the parent process outlives the child, so leaking
      fds won't result in them never being closed; and in any case we're
      reasonably careful to set CLOEXEC on all our fds. So let's just not
      close them.
      
      In particular, this can save literally a million syscalls per helper
      subprocess invocation (it's not often I get to say that!), reducing
      pressure-vessel-wrap launch time by 90% on a system with the high fd
      limit (about 70 seconds down to 7). With the recommended soft limit of
      1024, the speedup is less dramatic, but it still takes off nearly 10%
      (about 6 down to 5.5).
      
      Resolves: https://github.com/ValveSoftware/steam-runtime/issues/323
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      97b5a8f6
  19. Dec 10, 2020
  20. Dec 03, 2020
  21. Oct 22, 2020
    • Simon McVittie's avatar
      pressure-vessel: Disable GIO modules differently · 92b1c2b6
      Simon McVittie authored
      
      Now that GIO_MODULE_DIR has been backported into scout's GLib, we can
      disable GIO modules completely, instead of loading them but then not
      using them. This avoids some misleading warnings (#32).
      
      This will not be completely effective on non-Debian systems until we
      also patch scout's GLib to make GIO_MODULE_DIR take precedence over
      the hard-coded legacy search path /usr/lib/gio/modules.
      
      The unit test for this is still in tests/pressure-vessel/utils.c
      for now.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      92b1c2b6
  22. Sep 29, 2020
  23. Sep 28, 2020
  24. Sep 25, 2020
  25. Sep 09, 2020
  26. Sep 02, 2020
  27. Aug 19, 2020
  28. Aug 18, 2020
  29. Aug 04, 2020
  30. Aug 03, 2020
Loading