1. 18 Aug, 2020 3 commits
  2. 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
      03a53a95
    • 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
      53c94972
  3. 06 Aug, 2020 2 commits
  4. 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
      d2a232ae
    • 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.
      47cdc8e3
  5. 02 Jul, 2020 3 commits
  6. 25 Jun, 2020 1 commit
  7. 24 Jun, 2020 10 commits
  8. 22 Jun, 2020 1 commit
  9. 09 Jun, 2020 1 commit
  10. 08 Jun, 2020 1 commit
  11. 05 Jun, 2020 2 commits
    • LRN's avatar
      GWin32RegistryKey: Move assertions · 98570e2d
      LRN authored and Philip Withnall's avatar Philip Withnall committed
      While these assertions look right at the first glance,
      they actually crash the program. That's because GObject
      insists on initializing all construct-only properties
      to their default values, which results in
      g_win32_registry_key_set_property() being called multiple
      times with NULL string, once for each unset property.
      
      If "path" is actually set by the caller, a subsequent
      call to set "path-utf16" to NULL will fail an assertion,
      since absolute_path is already non-NULL.
      
      With assertions moved the set-to-NULL calls bail out before
      an assertion is made.
      98570e2d
    • Chun-wei Fan's avatar
      glib-compile-resources: Fix exporting on Visual Studio · e56a2865
      Chun-wei Fan authored and Philip Withnall's avatar Philip Withnall committed
      Have the generated .c code decorate the prototypes with "G_MODULE_EXPORT"
      instead of "extern" when --internal is not being used, so that we also
      export the symbols from the generated code on Visual Studio-style
      compilers.  If --internal is used, we decorate the prototypes with
      "G_GNUC_INTERNAL", as we did before.
      
      Note that since the generated .c code does not attempt to include the
      generated headers (if one is also generated), the gnerated headers are
      still generated as they were before.
      e56a2865
  12. 22 May, 2020 2 commits
  13. 20 May, 2020 1 commit
  14. 19 May, 2020 4 commits
  15. 17 May, 2020 3 commits
  16. 14 May, 2020 2 commits