1. 11 Feb, 2021 9 commits
  2. 08 Feb, 2021 6 commits
  3. 04 Feb, 2021 13 commits
  4. 03 Feb, 2021 5 commits
  5. 02 Feb, 2021 1 commit
  6. 01 Feb, 2021 4 commits
    • Simon McVittie's avatar
    • Thomas Haller's avatar
      spawn: prefer allocating buffers on stack for small sizes to avoid valgrind leaks · 8a3c3b8c
      Thomas Haller authored
      We preallocate buffers that are used after forked. That is because
      malloc()/free() are not async-signal-safe and must not be used between
      fork() and exec().
      However, for the child process that exits without fork, valgrind wrongly
      reports these buffers as leaked.
      That can be suppressed with "--child-silent-after-fork=yes", but it is
      Work around by trying to allocate the buffers on the stack. At
      least in the common cases where the pointers are small enough
      so that we can reasonably do that.
      If the buffers happen to be large, we still allocate them on the heap
      and the problem still happens. Maybe we could have also allocated them
      as thread_local, but currently glib doesn't use that.
      [smcv: Cosmetic adjustments to address review comments from pwithnall]
    • Simon McVittie's avatar
      Add test coverage for G_SPAWN_SEARCH_PATH · 136a9d7f
      Simon McVittie authored
      For manual test coverage that would reproduce the bug fixed in !1902
      copy /bin/true (or any other harmless executable) to
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
      spawn: Don't set a search path if we don't want to search PATH · 0d50c6bb
      Simon McVittie authored
      do_exec() and g_execute() rely on being passed a NULL search path
      if we intend to avoid searching the PATH, but since the refactoring
      in commit 62ce66d4, this was never done. This resulted in some spawn
      calls searching the PATH when it was not intended.
      Spawn calls that go through the posix_spawn fast-path were unaffected.
      The deprecated gtester utility, as used in GTK 3, relies on the
      ability to run an executable from the current working directory by
      omitting the G_SPAWN_SEARCH_PATH flag. This *mostly* worked, because
      our fallback PATH ends with ".". However, if an executable of the
      same name existed in /usr/bin or /bin, it would run that instead of the
      intended test: in particular, GTK 3's build-time tests failed if
      ImageMagick happens to be installed, because gtester would accidentally
      run display(1) instead of testsuite/gdk/display.
      Fixes: 62ce66d4 "gspawn: Don’t use getenv() in async-signal-safe context"
      Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977961
  7. 11 Jan, 2021 2 commits