1. 16 Jun, 2020 1 commit
  2. 10 Jun, 2020 1 commit
  3. 05 Jun, 2020 1 commit
  4. 18 Mar, 2020 1 commit
  5. 10 Mar, 2020 3 commits
  6. 07 Mar, 2020 1 commit
  7. 28 Feb, 2020 8 commits
  8. 27 Feb, 2020 1 commit
  9. 24 Feb, 2020 1 commit
  10. 18 Feb, 2020 6 commits
  11. 17 Feb, 2020 5 commits
  12. 16 Feb, 2020 4 commits
    • Philip Withnall's avatar
      Merge branch 'cherry-pick-2722620e' into 'glib-2-62' · 9f4af274
      Philip Withnall authored
      Refactor g_socket_client_connect_async()
      
      See merge request !1365
      9f4af274
    • Patrick Griffis's avatar
      Refactor g_socket_client_connect_async() · 08677ed5
      Patrick Griffis authored and Philip Withnall's avatar Philip Withnall committed
      This is a fairly large refactoring. The highlights are:
      
      - Removing in-progress connections/addresses from GSocketClientAsyncConnectData:
      
        This caused issues where multiple ConnectionAttempt's would step over eachother
        and modify shared state causing bugs like accidentally bypassing a set proxy.
      
        Fixes #1871
        Fixes #1989
        Fixes #1902
      
      - Cancelling address enumeration on error/completion
      
      - Queuing successful TCP connections and doing application layer work serially:
      
        This is more in the spirit of Happy Eyeballs but it also greatly simplifies
        the flow of connection handling so fewer tasks are happening in parallel
        when they don't need to be.
      
        The behavior also should more closely match that of g_socket_client_connect().
      
      - Better track the state of address enumeration:
      
        Previously we were over eager to treat enumeration finishing as an error.
      
        Fixes #1872
        See also #1982
      
      - Add more detailed documentation and logging.
      
      Closes #1995
      
      
      (cherry picked from commit 2722620e)
      08677ed5
    • Simon McVittie's avatar
      tests: Cope with having CAP_DAC_OVERRIDE, even if not euid 0 · 5a6f6941
      Simon McVittie authored and Philip Withnall's avatar Philip Withnall committed
      
      
      Some CI platforms invoke these tests with euid != 0 but with
      capabilities. Detect whether we have Linux CAP_DAC_OVERRIDE or other
      OSs' equivalents, and skip tests that rely on DAC permissions being
      denied if we do have that privilege.
      
      (Cherry pick to 2.62: Fix one minor cherry-pick conflict.)
      
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Fixes: #2027
      Fixes: #2028
      5a6f6941
    • Simon McVittie's avatar
      tests: Don't assume that unprivileged uids are bound by RLIMIT_NPROC · 58401555
      Simon McVittie authored and Philip Withnall's avatar Philip Withnall committed
      
      
      Some CI platforms invoke tests as euid != 0, but with capabilities that
      include CAP_SYS_RESOURCE and/or CAP_SYS_ADMIN. If we detect this,
      we can't test what happens if our RLIMIT_NPROC is too low to create a
      thread, because RLIMIT_NPROC is bypassed in these cases.
      
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Fixes: #2029
      58401555
  13. 12 Feb, 2020 5 commits
    • Sebastian Dröge's avatar
      Merge branch 'backport-1353-source-refs-glib-2-62' into 'glib-2-62' · 088cfde0
      Sebastian Dröge authored
      Backport !1353 GMainContext source reference fixes to glib-2-62
      
      See merge request !1361
      088cfde0
    • Sebastian Dröge's avatar
      GMainContext - Add tests for !1353 and related situations · 3c517fb0
      Sebastian Dröge authored and Philip Withnall's avatar Philip Withnall committed
      3c517fb0
    • Sebastian Dröge's avatar
      GMainContext - Move mutex unlocking in destructor right before freeing the mutex · 8258bbfe
      Sebastian Dröge authored and Philip Withnall's avatar Philip Withnall committed
      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.
      8258bbfe
    • Sebastian Dröge's avatar
      GMainContext - Fix memory leaks and memory corruption when freeing sources while freeing a context · c2786123
      Sebastian Dröge authored and Philip Withnall's avatar Philip Withnall committed
      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.
      c2786123
    • Sebastian Dröge's avatar
      GMainContext - Fix GSource iterator if iteration can modify the list · 14ddde47
      Sebastian Dröge authored and Philip Withnall's avatar Philip Withnall committed
      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
      14ddde47
  14. 09 Feb, 2020 1 commit
  15. 06 Feb, 2020 1 commit