1. 11 Sep, 2022 1 commit
  2. 08 Oct, 2019 1 commit
  3. 02 Sep, 2019 4 commits
  4. 27 Aug, 2019 6 commits
    • Sebastian Dröge's avatar
      Merge branch 'backport-1040-settings-backend-race-glib-2-60' into 'glib-2-60' · 33905dd9
      Sebastian Dröge authored
      Backport !1040 “GSettingsBackend - Fix thread-safety during destruction of GSettings instances...” to glib-2-60
      
      See merge request !1065
      33905dd9
    • Sebastian Dröge's avatar
      GSettingsBackend - Fix thread-safety during destruction of GSettings instances... · 88fd610a
      Sebastian Dröge authored and Philip Withnall's avatar Philip Withnall committed
      GSettingsBackend - Fix thread-safety during destruction of GSettings instances while notifications are emitted
      
      g_settings_backend_watch() uses a weak notify for keeping track of
      the target. There's an explanation why this is supposed to be safe but
      that explanation is wrong.
      
      The following could happen before:
      
      1. We have the target stored in the watch list
      2. The last reference to the target is dropped in thread A and we end up
         in g_settings_backend_watch_weak_notify() right before the mutex
      3. g_settings_backend_dispatch_signal() is called from another thread B
         and gets the mutex before 2.
      4. g_weak_ref_init() is called on the target from thread B, which at
         this point has a reference count of exactly one (see g_object_unref()
         where it calls the weak notifies)
      5. Thread A continues at 3. and drops the last reference and destroys
         the object. Now the GWeakRef from 4. points to a destroyed object. Note
         that GWeakRefs would be cleared before the weak notifies are called
      6. At some later point another thread g_weak_ref_get() is called by
         g_settings_backend_invoke_closure() and accesses an already destroyed
         object with refcount 0 from the GWeakRef created in 4. by thread B (or
         worse, already freed memory that was reused).
      
      Solve this by actually storing a GWeakRef of the target in the watch
      list and only access the target behind it via the GWeakRef API, and then
      pass a strong reference to the notification dispatch code.
      
      The weak notify is only used to remove the (potentially with empty
      GWeakRef) target from the list of watches and the only place that
      compares the target by pointer instead of going through the GWeakRef
      API.
      
      Fixes #1870
      88fd610a
    • Nirbheek Chauhan's avatar
      Merge branch 'backport-966-win32-uri-crash-fix' into 'glib-2-60' · 6a9d6c27
      Nirbheek Chauhan authored
      Backport !966 “Resolve "Invalid characters in Open Location dialog crashes GIMP"” to glib-2-60
      
      See merge request !1061
      6a9d6c27
    • Philip Withnall's avatar
      gwinhttpvfs: Fall back to wrapped VFS if creating a HTTP file fails · 87c81689
      Philip Withnall authored
      
      
      If we fail to create a GWinhttpFile for a URI (for example, because it’s
      an invalid URI or is badly encoded), don’t just return NULL. Instead,
      fall back to the wrapped VFS which might be able to handle it instead.
      
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      
      Fixes: #1819
      87c81689
    • Philip Withnall's avatar
      gwinhttpfile: Document constructor as potentially returning NULL · 7b90d507
      Philip Withnall authored
      
      
      It can return NULL if the URI was badly encoded or couldn’t be handled
      by Windows’ API.
      
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      
      Helps: #1819
      7b90d507
    • Philip Withnall's avatar
      gvfs: Add an assertion to check that get_file_for_uri() is never NULL · 9dac535c
      Philip Withnall authored
      
      
      It cannot return a NULL value, as none of its callers have error
      handlng. Add an assertion to check the values returned by the VFS
      implementations.
      
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      
      Helps: #1819
      9dac535c
  5. 05 Aug, 2019 1 commit
  6. 29 Jul, 2019 2 commits
  7. 24 Jul, 2019 1 commit
  8. 15 Jul, 2019 4 commits
  9. 09 Jul, 2019 6 commits
  10. 04 Jul, 2019 2 commits
  11. 02 Jul, 2019 1 commit
    • Allison Karlitskaya's avatar
      gthread: fix minor errno problem in GCond · e4c9a621
      Allison Karlitskaya authored and Philip Withnall's avatar Philip Withnall committed
      The return value from `g_cond_wait_until()` is calculated, based on the
      value of `errno` after reacquiring the mutex.  This is a problem because
      `errno` can be overwritten in the case the mutex is contended (in which
      case the slow-path code will re-enter the kernel).
      
      Perform the calculation before reacquiring the mutex.
      
      See merge request !958
      e4c9a621
  12. 27 Jun, 2019 1 commit
  13. 24 Jun, 2019 1 commit
  14. 11 Jun, 2019 7 commits
  15. 10 Jun, 2019 2 commits