1. 01 Oct, 2020 7 commits
  2. 30 Sep, 2020 2 commits
    • Peter Bloomfield's avatar
      gthreadedresolver: Fix logic in parse_res_text() · 9ded33cf
      Peter Bloomfield authored and Philip Withnall's avatar Philip Withnall committed
      and avoid a sign-compare warning.
      Fixes #2209
    • Christoph Reiter's avatar
      Fix g_module_symbol() under Windows sometimes not succeeding · 0d3ba090
      Christoph Reiter authored and Philip Withnall's avatar Philip Withnall committed
      g_module_symbol() internally calls CreateToolhelp32Snapshot() which
      in some circumstances returns ERROR_BAD_LENGTH and according to the docs
      should lead to CreateToolhelp32Snapshot() being retried by the caller.
      This retry logic was missing and for example led to g_module_symbol()
      not succeeding if another thread happened to call the wrong function
      at the wrong time.
      This got noticed in the g-i build of gtk4 where g-i would call g_module_symbol()
      on all gtk4 _get_type symbols and while inspecting the properties gtk4 would
      spawn a thread calling SHGetSpecialFolderLocation() somewhere down the line.
      During the call to SHGetSpecialFolderLocation() CreateToolhelp32Snapshot() would
      return with ERROR_BAD_LENGTH for a short period of time and make g_module_symbol()
      fail, which lead to "Invalid GType function" errors in g-i.
      Fixes gtk#3213
  3. 23 Sep, 2020 3 commits
  4. 22 Sep, 2020 1 commit
  5. 21 Sep, 2020 1 commit
  6. 11 Sep, 2020 2 commits
  7. 05 Sep, 2020 1 commit
  8. 03 Sep, 2020 2 commits
  9. 01 Sep, 2020 4 commits
    • Carlos Garnacho's avatar
      tests: Add splice cancellation test · 1b03204e
      Carlos Garnacho authored and Philip Withnall's avatar Philip Withnall committed
      This doesn't trigger the cancellation assertion issue when run locally
      (the task didn't return yet, so the error is simply overwritten), but
      perhaps it ever does in CI. Anyhow, it's good to have a cancellation
    • Carlos Garnacho's avatar
      goutputstream: Check individual close operations after splice · 40865e0b
      Carlos Garnacho authored and Philip Withnall's avatar Philip Withnall committed
      After a splice operation is finished, it attempts to 1) close input/output
      streams, as per the given flags, and 2) return the operation result (maybe
      an error, too).
      However, if the operation gets cancelled early and the streams indirectly
      closed, the splice operation will try to close both descriptors and return
      on the task when both are already closed. The catch here is that getting the
      streams closed under its feet is possible, so the completion callback would
      find both streams closed after returning on the first close operation and
      return the error, but then the second operation could be able to trigger
      a second error which would be returned as well.
      What happens here is up to further race conditions, if the task didn't
      return yet, the returned error will be simply replaced (but the old one not
      freed...), if it did already return, it'll result in:
      GLib-GIO-FATAL-CRITICAL: g_task_return_error: assertion '!task->ever_returned' failed
      Fix this by flagging the close_async() callbacks, and checking that both
      close operations did return, instead of checking that both streams are
      closed by who knows.
      This error triggers a semi-frequent CI failure in tracker, see the summary at
    • Sebastian Dröge's avatar
      Don't pass more than G_MAXSSIZE bytes at once to write() in glib/gfileutils.c · 259903ca
      Sebastian Dröge authored and Philip Withnall's avatar Philip Withnall committed
      Behaviour in that case is implementation-defined and how many bytes were
      actually written can't be expressed by the return value anymore.
      Instead do a short write of G_MAXSSIZE bytes and let the existing loop
      for handling short writes takes care of the remaining length.
    • Emmanuel Fleury's avatar
      Fixing signedness warning in glib/gfileutils.c · 3ff911af
      Emmanuel Fleury authored and Philip Withnall's avatar Philip Withnall committed
      glib/gfileutils.c: In function ‘write_to_file’:
      glib/gfileutils.c:1176:19: error: comparison of integer expressions of different signedness: ‘gssize’ {aka ‘long int’} and ‘gsize’ {aka ‘long unsigned int’} [-Werror=sign-compare]
       1176 |       g_assert (s <= length);
            |                   ^~
      glib/gmacros.h:939:25: note: in definition of macro ‘G_LIKELY’
        939 | #define G_LIKELY(expr) (expr)
            |                         ^~~~
      glib/gfileutils.c:1176:7: note: in expansion of macro ‘g_assert’
       1176 |       g_assert (s <= length);
            |       ^~~~~~~~
      Related to issue #1735 (Get back to a -werror build)
  10. 18 Aug, 2020 3 commits
  11. 17 Aug, 2020 2 commits
    • Sebastian Dröge's avatar
      Merge branch 'backport-1617-subprocess-blocking-glib-2-64' into 'glib-2-64' · 03a53a95
      Sebastian Dröge authored
      Backport !1617 “Ensure g_subprocess_communicate_async() never blocks” to glib-2-64
      See merge request !1618
    • Alexander Larsson's avatar
      Ensure g_subprocess_communicate_async() never blocks · 53c94972
      Alexander Larsson authored and Philip Withnall's avatar Philip Withnall committed
      It turns out that our async write operation implementation is broken
      on non-O_NONBLOCK pipes, because the default async write
      implementation calls write() after poll() said there were some
      space. However, the semantics of pipes is that unless O_NONBLOCK is set
      then the write *will* block if the passed in write count is larger than
      the available space.
      This caused a deadlock in #2182
      due to the loop-back of the app stdout to the parent, but even without such
      a deadlock it is a problem that we may block the mainloop at all.
      In the particular case of g_subprocess_communicate() we have full
      control of the pipes after starting the app, so it is safe to enable
      O_NONBLOCK (i.e. we can ensure all the code using the fd after this can handle
      non-blocking mode).
      This fixes #2182
  12. 06 Aug, 2020 2 commits
  13. 06 Jul, 2020 2 commits
    • Emmanuele Bassi's avatar
      Merge branch 'backport-1563-desktop-app-info-leak-glib-2-64' into 'glib-2-64' · d2a232ae
      Emmanuele Bassi authored
      Backport !1563 “gdesktopappinfo: Fix unnecessarily copied and leaked URI list” to glib-2-64
      See merge request !1565
    • Felix Riemann's avatar
      gdesktopappinfo: Fix unnecessarily copied and leaked URI list · 47cdc8e3
      Felix Riemann authored and Philip Withnall's avatar Philip Withnall committed
      When an app is spawned using g_desktop_app_info_launch_uris_with_spawn
      it will expand the various token in the app's commandline with the
      URIs of the files to open. The expand_macro() function that is used for
      this advances the pointer to the URI list to show up to which entries
      it used.
      To not loose the pointer to the list head a duplicate of the URI list
      was actually passed to expand_macro(). However, it's not necessary to
      create a copy of the URI list for that as expand_macro() will only
      change which element the pointer will point to.
      This behaviour actually caused the duplicated list to be leaked as the
      the list pointer is NULL once all URIs are used up by expand_macro()
      and thus nothing was freed at the end of the function.
  14. 02 Jul, 2020 3 commits
  15. 25 Jun, 2020 1 commit
  16. 24 Jun, 2020 4 commits