1. 12 Dec, 2012 1 commit
    • Dan Winship's avatar
      Add gnetworking.h · b377e696
      Dan Winship authored
      Install a public "gnetworking.h" header that can be used to include
      the relevant OS-dependent networking headers. This does not really
      abstract away unix-vs-windows however; error codes, in particular,
      are incompatible.
      
      gnetworkingprivate.h now contains just a few internal URI-related
      functions
      
      Also add a g_networking_init() function to gnetworking.h, which can be
      used to explicitly initialize OS-level networking, rather than having
      that happen as a side-effect of registering GInetAddress.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=623187
      b377e696
  2. 02 Nov, 2012 1 commit
  3. 16 Oct, 2012 1 commit
  4. 28 Aug, 2012 1 commit
  5. 19 Apr, 2012 1 commit
  6. 18 Apr, 2012 2 commits
  7. 08 Apr, 2012 1 commit
  8. 02 Jan, 2012 1 commit
  9. 15 Dec, 2011 1 commit
  10. 02 Dec, 2011 1 commit
  11. 13 Oct, 2011 2 commits
  12. 10 Oct, 2011 1 commit
  13. 08 Oct, 2011 1 commit
  14. 30 Aug, 2011 1 commit
  15. 24 Jul, 2011 1 commit
  16. 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
  17. 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
  18. 14 Apr, 2011 1 commit
  19. 13 Apr, 2011 1 commit
  20. 02 Dec, 2010 1 commit
  21. 19 Oct, 2010 1 commit
  22. 09 Sep, 2010 2 commits
  23. 04 Sep, 2010 1 commit
  24. 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
  25. 27 Aug, 2010 1 commit
  26. 23 Aug, 2010 1 commit
  27. 06 Aug, 2010 1 commit
  28. 22 Aug, 2010 2 commits
  29. 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
  30. 13 Aug, 2010 1 commit
  31. 30 Jul, 2010 1 commit
  32. 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
  33. 19 Jul, 2010 2 commits
  34. 16 Jul, 2010 1 commit