1. 02 Dec, 2011 1 commit
  2. 13 Oct, 2011 2 commits
  3. 10 Oct, 2011 1 commit
  4. 08 Oct, 2011 1 commit
  5. 30 Aug, 2011 1 commit
  6. 24 Jul, 2011 1 commit
  7. 20 Jun, 2011 1 commit
    • David Zeuthen's avatar
      GDBus: Unref worker from worker-thread to avoid race · 322e25b5
      David Zeuthen authored
      ... otherwise we might end up using the worker after it has been
      freed. Reported by Dan Winship and Colin Walters.
      
      This fix uncovered a bug in the /gdbus/nonce-tcp test case so "fix"
      that as well to use a better way of having one thread wait for another
      (using quotes for the word "fix" since it's pretty hackish to
      busy-wait in one thread to wait for another).
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      322e25b5
  8. 03 May, 2011 1 commit
    • Dan Winship's avatar
      Fix usage of _GNU_SOURCE · e56498ee
      Dan Winship authored
      _GNU_SOURCE must be defined before including any other (system)
      header, so defining it in glib-unix.h (and hoping no one has included
      anything else before that) is wrong. And the "#define _USE_GNU"
      workaround for this problem in gnetworkingprivate.h is even wronger
      (and still prone to failure anyway due to single-include guards).
      
      Fix this by defining _GNU_SOURCE in config.h when building against
      glibc. In theory this is bad because new releases of glibc may include
      symbols that conflict with glib symbols, which could then cause
      compile failures. However, most people only see new releases of glibc
      when they upgrade their distro, at which point they also generally get
      new releases of gcc, which have new warnings/errors to clean up
      anyway.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=649201
      e56498ee
  9. 14 Apr, 2011 1 commit
  10. 13 Apr, 2011 1 commit
  11. 02 Dec, 2010 1 commit
  12. 19 Oct, 2010 1 commit
  13. 09 Sep, 2010 2 commits
  14. 04 Sep, 2010 1 commit
  15. 03 Sep, 2010 2 commits
    • Christian Persch's avatar
      Plug some mem leaks in gdbus-peer test · be33ef85
      Christian Persch authored
      ==29535== 56 (24 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 1,112 of 1,264
      ==29535==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
      ==29535==    by 0x4057094: g_malloc (gmem.c:134)
      ==29535==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
      ==29535==    by 0x406F364: g_slice_copy (gslice.c:858)
      ==29535==    by 0x403A9B2: g_error_copy (gerror.c:160)
      ==29535==    by 0x42066D3: initable_init (gdbusconnection.c:2314)
      ==29535==    by 0x41A73E5: g_initable_init (ginitable.c:105)
      ==29535==    by 0x41A7587: g_initable_new_valist (ginitable.c:218)
      ==29535==    by 0x41A742A: g_initable_new (ginitable.c:138)
      ==29535==    by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
      ==29535==    by 0x804D63A: test_nonce_tcp (gdbus-peer.c:1229)
      
      ==29535== 107 (24 direct, 83 indirect) bytes in 1 blocks are definitely lost in loss record 1,188 of 1,264
      ==29535==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
      ==29535==    by 0x4057094: g_malloc (gmem.c:134)
      ==29535==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
      ==29535==    by 0x406F364: g_slice_copy (gslice.c:858)
      ==29535==    by 0x403A9B2: g_error_copy (gerror.c:160)
      ==29535==    by 0x42066D3: initable_init (gdbusconnection.c:2314)
      ==29535==    by 0x41A73E5: g_initable_init (ginitable.c:105)
      ==29535==    by 0x41A7587: g_initable_new_valist (ginitable.c:218)
      ==29535==    by 0x41A742A: g_initable_new (ginitable.c:138)
      ==29535==    by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
      ==29535==    by 0x804D8E8: test_nonce_tcp (gdbus-peer.c:1259)
      
      ==29535== 112 (24 direct, 88 indirect) bytes in 1 blocks are definitely lost in loss record 1,193 of 1,264
      ==29535==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
      ==29535==    by 0x4057094: g_malloc (gmem.c:134)
      ==29535==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
      ==29535==    by 0x406F364: g_slice_copy (gslice.c:858)
      ==29535==    by 0x403A9B2: g_error_copy (gerror.c:160)
      ==29535==    by 0x42066D3: initable_init (gdbusconnection.c:2314)
      ==29535==    by 0x41A73E5: g_initable_init (ginitable.c:105)
      ==29535==    by 0x41A7587: g_initable_new_valist (ginitable.c:218)
      ==29535==    by 0x41A742A: g_initable_new (ginitable.c:138)
      ==29535==    by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
      ==29535==    by 0x804D79A: test_nonce_tcp (gdbus-peer.c:1248)
      
      ==29535== 73 (24 direct, 49 indirect) bytes in 1 blocks are definitely lost in loss record 1,152 of 1,264
      ==29535==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
      ==29535==    by 0x4057094: g_malloc (gmem.c:134)
      ==29535==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
      ==29535==    by 0x406F364: g_slice_copy (gslice.c:858)
      ==29535==    by 0x403A9B2: g_error_copy (gerror.c:160)
      ==29535==    by 0x42066D3: initable_init (gdbusconnection.c:2314)
      ==29535==    by 0x41A73E5: g_initable_init (ginitable.c:105)
      ==29535==    by 0x41A7587: g_initable_new_valist (ginitable.c:218)
      ==29535==    by 0x41A742A: g_initable_new (ginitable.c:138)
      ==29535==    by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
      ==29535==    by 0x804C6CE: test_peer (gdbus-peer.c:803)
      
      Bug #628331.
      be33ef85
    • Christian Persch's avatar
      Plug a mem leak in the gdbus-peer test · 3df58661
      Christian Persch authored
      ==6793== 32 (24 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 779 of 1,423
      ==6793==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
      ==6793==    by 0x4057094: g_malloc (gmem.c:134)
      ==6793==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
      ==6793==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
      ==6793==    by 0x413D5BB: g_type_create_instance (gtype.c:1867)
      ==6793==    by 0x412372A: g_object_constructor (gobject.c:1482)
      ==6793==    by 0x4122E1D: g_object_newv (gobject.c:1266)
      ==6793==    by 0x4122B93: g_object_new (gobject.c:1178)
      ==6793==    by 0x41DB4F9: g_unix_fd_list_new (gunixfdlist.c:159)
      ==6793==    by 0x804AADD: test_interface_method_call (gdbus-peer.c:172)
      
      Bug #628331.
      3df58661
  16. 27 Aug, 2010 1 commit
  17. 23 Aug, 2010 1 commit
  18. 06 Aug, 2010 1 commit
  19. 22 Aug, 2010 2 commits
  20. 16 Aug, 2010 1 commit
    • David Zeuthen's avatar
      Bug 626748 – Use async methods for writing and handle EAGAIN · 8a3a4596
      David Zeuthen authored
      If sending a lot of data and/or the other peer is not reading it, then
      socket buffers can overflow. This is communicated from the kernel by
      returning EAGAIN. In GIO, it is modelled by g_output_stream_write()
      and g_socket_send_message() returning G_IO_ERROR_WOULD_BLOCK.
      
      It is also problematic that that we're using synchronous IO in the
      shared GDBus IO thread. It means that one GDBusConnection can lock up
      others.
      
      It turns out that by porting from g_output_stream_write() to
      g_output_stream_write_async() we fix the EAGAIN issue. For GSocket, we
      still need to handle things manually (by creating a GSource) as
      g_socket_send_message() is used.
      
      We check the new behavior in Michael's producer/consumer test case (at
      /gdbus/overflow in gdbus-peer.c) added in the last commit.
      
      Also add a test case that sends and receives a 20 MiB message.
      
      Also add a new `transport' G_DBUS_DEBUG option so it is easy to
      inspect partial writes:
      
       $ G_DBUS_DEBUG=transport ./gdbus-connection -p /gdbus/connection/large_message
       [...]
       ========================================================================
       GDBus-debug:Transport:
         >>>> WROTE 128000 bytes of message with serial 4 and
              size 20971669 from offset 0 on a GSocketOutputStream
       ========================================================================
       GDBus-debug:Transport:
         >>>> WROTE 128000 bytes of message with serial 4 and
              size 20971669 from offset 128000 on a GSocketOutputStream
       ========================================================================
       GDBus-debug:Transport:
         >>>> WROTE 128000 bytes of message with serial 4 and
              size 20971669 from offset 256000 on a GSocketOutputStream
       [...]
       ========================================================================
       GDBus-debug:Transport:
         >>>> WROTE 43669 bytes of message with serial 4 and
              size 20971669 from offset 20928000 on a GSocketOutputStream
       [...]
       ========================================================================
       GDBus-debug:Transport:
         <<<< READ 16 bytes of message with serial 3 and
              size 20971620 to offset 0 from a GSocketInputStream
       ========================================================================
       GDBus-debug:Transport:
         <<<< READ 15984 bytes of message with serial 3 and
              size 20971620 to offset 16 from a GSocketInputStream
       ========================================================================
       GDBus-debug:Transport:
         <<<< READ 16000 bytes of message with serial 3 and
              size 20971620 to offset 16000 from a GSocketInputStream
       [...]
       ========================================================================
       GDBus-debug:Transport:
         <<<< READ 144000 bytes of message with serial 3 and
              size 20971620 to offset 20720000 from a GSocketInputStream
       ========================================================================
       GDBus-debug:Transport:
         <<<< READ 107620 bytes of message with serial 3 and
              size 20971620 to offset 20864000 from a GSocketInputStream
       OK
      
      https://bugzilla.gnome.org/show_bug.cgi?id=626748Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      8a3a4596
  21. 13 Aug, 2010 1 commit
  22. 30 Jul, 2010 1 commit
  23. 20 Jul, 2010 1 commit
    • David Zeuthen's avatar
      Bug 617483 – Credentials passing · 7eba4134
      David Zeuthen authored
       - Make GCredentials instance and class structures private so it can't
         be subclassed and we don't have to worry about ABI compat
         issues. This also allows us to get rid of the GCredentialsPrivate
         struct.
      
       - Add a GCredentialsType enumeration that is used whenever exchanging
         pointers with the user. This allows us to support OSes with
         multiple native credential types. In particular, it allows
         supporting OSes where the native credential evolves or even changes
         over time.
      
       - Add g_socket_get_credentials() method.
      
       - Add tests for g_socket_get_credentials(). Right now this is in the
         GDBus peer-to-peer test case but we can change that later.
      
       - Move GTcpConnection into a separate gtk-doc page as was already
         half-done with GUnixConnection. Also finish the GUnixConnection
         move and ensure send_credentials() and receive_credentials()
         methods are in the docs. Also nuke comment about GTcpConnection
         being empty compared to its superclass.
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      7eba4134
  24. 19 Jul, 2010 2 commits
  25. 16 Jul, 2010 1 commit
  26. 14 Jul, 2010 1 commit
  27. 01 Jul, 2010 1 commit
  28. 30 Jun, 2010 2 commits
  29. 11 Jun, 2010 1 commit
  30. 20 May, 2010 1 commit
    • David Zeuthen's avatar
      Bug 619142 – Build fixes · 366b3ffc
      David Zeuthen authored
       - Fix various #include issues
      
       - Change #error to #warning for the EXTERNAL authentication mechanism.
         It is not clear if this should work on Win32 at all.
      
       - Call close() before unlink() for the SHA1 keyring
      
       - Change #error to #warning so we don't forget to do
         permission checking of the .dbus-keyrings directory
      
       - Use Win32 SID for the SHA1 auth mech
      
       - Apparently we can't use word 'interface' as an identifier
      
       - Implement a _g_dbus_win32_get_user_sid() function. For now it's
         private. Don't know if it should be public somewhere. Maybe in
         a future GCredentials support for Win32? I don't know.
      
       - GFileDescriptorBased is not available on Win32. So avoid using
         it in GLocalFile stuff. Now, Win32 still uses GLocalFile + friends
         (which works with file descriptors) so expose a private function
         to get the fd for an OutputStream so things still work.
      
       - Fixup gio.symbols
      
       - Fixup tests/gdbus-peer.c so it builds
      
      With this, at least things compile and the gdbus-peer.exe test case
      passes. Which is a great start. I've tested this by cross-compiling on
      a x86_64 Fedora 13 host using mingw32 and running the code on a 32-bit
      Windows 7 box.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=619142Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      366b3ffc
  31. 14 May, 2010 2 commits
  32. 13 May, 2010 2 commits