1. 20 Dec, 2018 1 commit
  2. 15 Nov, 2018 1 commit
  3. 13 Nov, 2018 1 commit
  4. 25 Sep, 2018 1 commit
  5. 10 Jul, 2018 1 commit
  6. 25 Jun, 2018 1 commit
  7. 08 Jun, 2018 1 commit
  8. 19 Apr, 2018 1 commit
  9. 10 Apr, 2018 1 commit
  10. 15 Feb, 2018 1 commit
  11. 09 Jan, 2018 1 commit
  12. 04 Dec, 2017 1 commit
  13. 12 Nov, 2017 1 commit
  14. 26 Oct, 2017 1 commit
  15. 28 Jun, 2017 1 commit
  16. 29 May, 2017 1 commit
  17. 12 May, 2017 1 commit
    • Lars Uebernickel's avatar
      gdbus: fix use-after-free · 0751ccd3
      Lars Uebernickel authored
      g_dbus_connection_call_internal() accesses the user data it passes to
      g_dbus_connection_send_message_with_reply() after the call. That data
      might be freed already in the case that the callback is called
      immediately.
      
      Fix this by removing the 'serial' field from the user data altogether
      and fetch the serial from the message in the callback.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=748263
      0751ccd3
  18. 28 Apr, 2017 1 commit
  19. 08 Apr, 2017 1 commit
  20. 27 Mar, 2017 1 commit
  21. 14 Mar, 2017 3 commits
  22. 08 Feb, 2017 1 commit
  23. 05 Feb, 2017 1 commit
  24. 22 Nov, 2016 1 commit
  25. 24 Oct, 2016 1 commit
    • Matthias Clasen's avatar
      Partially revert 10c490cd · 2d56c49b
      Matthias Clasen authored
      This commit broke some tests, and I don't have the time
      to fix up all the expected output, so I'll revert the changes
      to the affected files for now.
      
      This needs to be redone with the necessary test fixes.
      2d56c49b
  26. 12 Oct, 2016 1 commit
  27. 29 Jun, 2016 1 commit
  28. 01 Mar, 2016 1 commit
  29. 06 Oct, 2015 1 commit
  30. 12 Sep, 2015 1 commit
  31. 24 Aug, 2015 1 commit
    • Dan Winship's avatar
      gdbus: fix race condition in connection filter freeing · 7da3922d
      Dan Winship authored
      If you called g_dbus_connection_remove_filter() on a filter while it
      was running (or about to be run) in another thread, its GDestroyNotify
      would be run immediately, potentially causing the filter thread to
      crash.
      
      Fix this by refcounting the filters, and using the existing mechanism
      for running a GDestroyNotify in another thread in the case where the
      the gdbus thread is the one that frees it.
      
      Also, add a bit of documentation explaining this (and add a related
      clarification to g_dbus_connection_signal_subscribe()).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=704568
      7da3922d
  32. 18 Aug, 2015 1 commit
  33. 06 Aug, 2015 1 commit
    • Colin Walters's avatar
      gdbusconnection: Don't g_printerr() when exiting · 66bc9660
      Colin Walters authored
      exit-on-close for a DBus connection is a completely normal thing.  On
      a regular GNOME login, gdm retains the X server, but terminates the
      session login bus and associated helpers like gnome-settings-dameon,
      the a11y tools, etc.
      
      I've seen several downstream reports of confusion as to what these
      apparent error messages mean in the system log.  It doesn't help
      that they're so obtuse.
      
      We're also printing them to stderr, when this is not an error.
      
      The reason this was introduced is presumably some people were confused
      as to why their process exited when the system bus did.  But the
      solution for that I believe is documentation, not printing stuff to
      everyone's system log in normal operation.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742386
      66bc9660
  34. 21 Jul, 2015 1 commit
  35. 05 Jun, 2015 1 commit
  36. 21 Apr, 2015 1 commit
  37. 06 Apr, 2015 1 commit
  38. 04 Apr, 2015 1 commit