1. 19 Oct, 2020 1 commit
  2. 14 Oct, 2020 1 commit
    • Benjamin Berg's avatar
      gmain: Fix possible locking issue in source unref · 6077ec3e
      Benjamin Berg authored and Philip Withnall's avatar Philip Withnall committed
      When unref'ing child sources, the lock is already held. But instead of
      passing TRUE to g_source_unref_internal it currently passes whether the
      lock was already held outside of the current invocation. Just pass TRUE
      to fix this possible issue.
      6077ec3e
  3. 23 Jul, 2020 1 commit
    • Nirbheek Chauhan's avatar
      glib: Use g_getenv everywhere instead of getenv · c3c2c313
      Nirbheek Chauhan authored
      `getenv()` doesn't work well on Windows, f.ex., it can't fetch env
      vars set with `SetEnvironmentVariable()`. This also means that it
      doesn't work at all when targeting UWP since that's the only way to
      set env vars in that case.
      c3c2c313
  4. 13 Jul, 2020 1 commit
  5. 07 Jul, 2020 1 commit
  6. 29 Jun, 2020 1 commit
    • Philip Withnall's avatar
      gmain: Fix use of atomic primitives with sig_atomic_t · da948f72
      Philip Withnall authored
      
      
      It seems that `sig_atomic_t` is not the same width as `int` on FreeBSD,
      which is causing CI failures:
      ```
       ../glib/gmain.c:5206:3: error: '_GStaticAssertCompileTimeAssertion_73' declared as an array with a negative size
        g_atomic_int_set (&any_unix_signal_pending, 0);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      ../glib/gatomic.h:100:5: note: expanded from macro 'g_atomic_int_set'
          G_STATIC_ASSERT (sizeof *(atomic) == sizeof (gint));                     \
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      ```
      
      Fix that by only using `sig_atomic_t` if the code is *not* using atomic
      primitives (i.e. in the fallback case). `sig_atomic_t` is only a typedef
      around an integer type and is not magic. Its typedef is chosen by the
      platform to be async-signal-safe (i.e. read or written in one instruction),
      but not necessarily thread-safe.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      da948f72
  7. 19 Jun, 2020 1 commit
    • Philip Withnall's avatar
      gmain: Access Unix signal handler state atomically · 253f5cda
      Philip Withnall authored
      
      
      There are two variables which are used to pass state from the Unix
      signal handler interrupt function to the rest of `gmain.c`. They are
      currently defined as `sig_atomic_t`, which means that they are
      guaranteed to be interrupt safe. However, it does not guarantee they are
      thread-safe, and GLib attaches its signal handler interrupt function to
      a worker thread.
      
      Make them thread-safe using atomics. It’s not possible to use locks, as
      pthread mutex functions are not signal-handler-safe. In particular, this
      means we have to be careful not to end up using GLib’s fallback atomics
      implementation, as that secretly uses a mutex. Better to be unsafe than
      have a re-entrant call into `pthread_mutex_lock()` from a nested signal
      handler.
      
      This commit solves two problems:
       1. Writes to `any_unix_signal_pending` and `unix_signal_pending` could
          be delivered out of order to the worker thread which calls
          `dispatch_unix_signals()`, resulting in signals not being handled
          until the next iteration of that worker thread. This is a
          performance problem but not a correctness problem.
       2. Setting an element of `unix_signal_pending` from
          `g_unix_signal_handler()` and clearing it from
          `dispatch_unix_signals_unlocked()` (in the worker thread) could
          race, resulting in a signal emission being cleared without being
          handled. That’s a correctness problem.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      
      Fixes: #1670
      253f5cda
  8. 11 Feb, 2020 3 commits
    • Sebastian Dröge's avatar
      GMainContext - Move mutex unlocking in destructor right before freeing the mutex · 730a75fc
      Sebastian Dröge authored
      This does not have any behaviour changes but is cleaner. The mutex is
      only unlocked now after all operations on the context are done and right
      before freeing the mutex and the context itself.
      730a75fc
    • Sebastian Dröge's avatar
      GMainContext - Fix memory leaks and memory corruption when freeing sources while freeing a context · aa20167d
      Sebastian Dröge authored
      Instead of destroying sources directly while freeing the context, and
      potentially freeing them if this was the last reference to them, collect
      new references of all sources in a separate list before and at the same
      time invalidate their context so that they can't access it anymore. Only
      once all sources have their context invalidated, destroy them while
      still keeping a reference to them. Once all sources are destroyed we get
      rid of the additional references and free them if nothing else keeps a
      reference to them anymore.
      
      This fixes a regression introduced by 26056558 in 2012.
      
      The previous code that invalidated the context of each source and then
      destroyed it before going to the next source without keeping an
      additional reference caused memory leaks or memory corruption depending
      on the order of the sources in the sources lists.
      
      If a source was destroyed it might happen that this was the last
      reference to this source, and it would then be freed. This would cause
      the finalize function to be called, which might destroy and unref
      another source and potentially free it. This other source would then
      either
      - go through the normal free logic and change the intern linked list
        between the sources, while other sources that are unreffed as part of
        the main context freeing would not. As such the list would be in an
        inconsistent state and we might dereference freed memory.
      - go through the normal destroy and free logic but because the context
        pointer was already invalidated it would simply mark the source as
        destroyed without actually removing it from the context. This would
        then cause a memory leak because the reference owned by the context is
        not freed.
      
      Fixes https://github.com/gtk-rs/glib/issues/583 while still keeping
      https://bugzilla.gnome.org/show_bug.cgi?id=661767 fixes.
      aa20167d
    • Sebastian Dröge's avatar
      GMainContext - Fix GSource iterator if iteration can modify the list · b06c48de
      Sebastian Dröge authored
      We first have to ref the next source and then unref the previous one.
      This might be the last reference to the previous source, and freeing the
      previous source might unref and free the next one which would then leave
      use with a dangling pointer here.
      
      Fixes #2031
      b06c48de
  9. 29 Nov, 2019 2 commits
    • Sebastian Dröge's avatar
      Add guards against invalid GSources to public GSource API · be1ec900
      Sebastian Dröge authored
      Especially check for a valid reference count. This is possible now in
      all cases because of the addition of the dispose function and makes
      usage of already finalized/finalizing GSources more obvious than the
      use-after-free that would otherwise happen.
      be1ec900
    • Sebastian Dröge's avatar
      Add g_source_set_dispose_function() for setting a dispose function for GSource · 0adf5cae
      Sebastian Dröge authored
      This allows GSource implementors to safely clear any other references to
      the GSource while the GSource is still valid, unlike when doing the same
      from the finalize function.
      
      After the dispose function has run, it is valid for the reference count
      of the GSource to be > 0 again to allow the case where another thread in
      the mean-time got access to the GSource reference before the dispose
      function was called.
      
      This allows fixing a thread-safety issue in the GCancellable, GstBus and
      various other GSource implementations.
      0adf5cae
  10. 25 Oct, 2019 1 commit
  11. 07 Oct, 2019 2 commits
  12. 05 Sep, 2019 1 commit
  13. 29 Jul, 2019 4 commits
  14. 29 Jun, 2019 1 commit
  15. 07 Jun, 2019 1 commit
  16. 28 May, 2019 1 commit
  17. 26 Apr, 2019 1 commit
  18. 15 Mar, 2019 1 commit
    • Emmanuel Fleury's avatar
      Fixing various warnings in glib/gmain.c · 81a4698c
      Emmanuel Fleury authored
      glib/gmain.c:480:1: error: missing initializer for field ‘closure_callback’ of ‘GSourceFuncs’ {aka ‘struct _GSourceFuncs’} [-Werror=missing-field-initializers]
       };
       ^
      In file included from glib/giochannel.h:33,
                       from glib/glib.h:54,
                       from glib/glib-unix.h:33,
                       from glib/gmain.c:50:
      glib/gmain.h:262:19: note: ‘closure_callback’ declared here
         GSourceFunc     closure_callback;
                         ^~~~~~~~~~~~~~~~
      glib/gmain.c:491:1: error: missing initializer for field ‘closure_callback’ of ‘GSourceFuncs’ {aka ‘struct _GSourceFuncs’} [-Werror=missing-field-initializers]
       };
       ^
      In file included from glib/giochannel.h:33,
                       from glib/glib.h:54,
                       from glib/glib-unix.h:33,
                       from glib/gmain.c:50:
      glib/gmain.h:262:19: note: ‘closure_callback’ declared here
         GSourceFunc     closure_callback;
                         ^~~~~~~~~~~~~~~~
      glib/gmain.c:499:1: error: missing initializer for field ‘closure_callback’ of ‘GSourceFuncs’ {aka ‘struct _GSourceFuncs’} [-Werror=missing-field-initializers]
       };
       ^
      In file included from glib/giochannel.h:33,
                       from glib/glib.h:54,
                       from glib/glib-unix.h:33,
                       from glib/gmain.c:50:
      glib/gmain.h:262:19: note: ‘closure_callback’ declared here
         GSourceFunc     closure_callback;
                         ^~~~~~~~~~~~~~~~
      glib/gmain.c:507:1: error: missing initializer for field ‘closure_callback’ of ‘GSourceFuncs’ {aka ‘struct _GSourceFuncs’} [-Werror=missing-field-initializers]
       };
       ^
      In file included from glib/giochannel.h:33,
                       from glib/glib.h:54,
                       from glib/glib-unix.h:33,
                       from glib/gmain.c:50:
      glib/gmain.h:262:19: note: ‘closure_callback’ declared here
         GSourceFunc     closure_callback;
                         ^~~~~~~~~~~~~~~~
      glib/gmain.c: In function ‘g_source_set_callback_indirect’:
      glib/gmain.c:1615:68: error: suggest braces around empty body in an ‘if’ statement [-Werror=empty-body]
                                                     callback_funcs->get));
                                                                          ^
      81a4698c
  19. 22 Feb, 2019 1 commit
  20. 07 Jan, 2019 1 commit
    • Philip Withnall's avatar
      gthread: Add g_private_set_alloc0() internal convenience API · f6caeb6d
      Philip Withnall authored
      
      
      This is a wrapper around g_private_set() which allocates the desired
      amount of memory for the caller and calls g_private_set() on it.
      
      This is intended to make it easier to suppress Valgrind warnings about
      leaked memory, since g_private_set() is typically used to make one-time
      per-thread allocations. We can now just add a blanket suppression rule
      for any allocations inside g_private_set_alloc0().
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      f6caeb6d
  21. 27 Nov, 2018 1 commit
    • Will Thompson's avatar
      gmain: clamp over-large timeouts · cdc2dd8e
      Will Thompson authored
      g_main_context_prepare() needs to calculate the timeout to pass to
      poll(), expressed in milliseconds as a gint.  But since the ready time
      for a GSource is represented by gint64 microseconds, it's possible that
      it could be more than G_MAXINT * 1000 microseconds in the future, and so
      can't be represented as a gint. This conversion to a narrower signed
      type is implementation-defined, but there are two possible outcomes:
      
      * the result is >= 0, in which case poll() will time out earlier than we
        might hope (with no adverse consequences besides an unwanted wakeup)
      * the result is < 0, in which case, if there are no other sources,
        poll() will block forever
      
      This is extremely unlikely to happen in practice, but can be avoided by
      clamping the gint64 value, which we know to be positive, to G_MAXINT.
      
      Thanks to Tomasz Miąsko for pointing this out on !496.
      cdc2dd8e
  22. 26 Nov, 2018 1 commit
    • Will Thompson's avatar
      g_timeout_*_seconds: don't overflow for large intervals · 4ff3734f
      Will Thompson authored
      Previously, the `guint interval` parameter, measured in seconds, was
      multiplied by 1000 and stored in another `guint` field. For intervals
      greater than (G_MAXUINT / 1000) seconds, this would overflow; the
      timeout would fire much sooner than intended.
      
      Since GTimeoutSource already keeps track of whether it was created at
      millisecond or second resolution, always store the passed interval
      directly. We later convert the interval to microseconds, stored in a
      gint64, so can move the `* 1000` to there.
      
      The eagle-eyed reader might notice that there is no obvious guarantee
      that the source's expiration time in microseconds won't overflow the
      gint64, but I don't think this is a new problem. Previously, the
      monotonic time would have to reach (2 ** 63 - 2 ** 32) microseconds for
      this overflow to occur; now it would have to reach approximately (2 **
      63 - 2 ** 42) microseconds. Both of these are 292.47 millennia to 5
      significant figures.
      
      Fixes #1600.
      4ff3734f
  23. 13 Nov, 2018 5 commits
  24. 29 Oct, 2018 1 commit
  25. 26 Jun, 2018 2 commits
    • Philip Withnall's avatar
      gmain: Officially deprecate g_main_context_wait() · 7a34e396
      Philip Withnall authored
      
      
      It’s been de-facto deprecated for a long time, due to emitting a
      critical warning when used in a non-internal context. Make that official
      in the documentation and with a deprecation annotation.
      
      Split the implementation into an internal helper and an external
      wrapper, so the two remaining internal uses don’t emit deprecation
      warnings.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      
      #903
      7a34e396
    • Philip Withnall's avatar
      gmain: Add names to various GSources constructed in GLib · 208a6e81
      Philip Withnall authored and Philip Withnall's avatar Philip Withnall committed
      For the purposes of debugging, it is quite useful for every GSource to
      have a name set. Ensure that any GSource we construct inside GLib has a
      name set. For GSources which are then returned to the caller, this name
      can then be overridden with something even more useful by the caller.
      
      Since this data is only used for debugging, avoid doing any allocations
      for it; just use static strings.
      
      #1175
      208a6e81
  26. 25 Jun, 2018 1 commit
  27. 14 Jun, 2018 1 commit
  28. 04 Jun, 2018 1 commit