1. 04 Apr, 2015 1 commit
  2. 31 Jan, 2014 1 commit
  3. 22 Jun, 2013 1 commit
  4. 28 Dec, 2012 1 commit
  5. 19 Apr, 2012 1 commit
  6. 18 Apr, 2012 2 commits
  7. 16 Sep, 2011 1 commit
  8. 25 Apr, 2011 1 commit
  9. 13 Apr, 2011 1 commit
  10. 08 Apr, 2011 1 commit
  11. 09 Sep, 2010 1 commit
  12. 23 Aug, 2010 1 commit
  13. 06 Aug, 2010 1 commit
  14. 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: 's avatarDavid Zeuthen <davidz@redhat.com>
      8a3a4596
  15. 04 Aug, 2010 1 commit
    • David Zeuthen's avatar
      GDBus: Add `return' debug option · d52e1c33
      David Zeuthen authored
      This prints all GDBusMethodInvocation API usage and is normally used
      with the `incoming' option. Example:
      
       # G_DBUS_DEBUG=incoming,return ./polkitd --replace
       Entering main event loop
       Connected to the system bus
       Registering null backend at priority -10
       [...]
       Acquired the name org.freedesktop.PolicyKit1
       [...]
      
       ========================================================================
       GDBus-debug:Incoming:
        <<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
             on object /org/freedesktop/PolicyKit1/Authority
             invoked by name :1.26
             serial 299
       ========================================================================
       GDBus-debug:Return:
        >>>> METHOD ERROR org.freedesktop.PolicyKit1.Error.Failed
             message `Cannot determine session the caller is in'
             in response to org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
             on object /org/freedesktop/PolicyKit1/Authority
             to name :1.26
             reply-serial 299
      
       [...]
      
       ========================================================================
       GDBus-debug:Incoming:
        <<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
             on object /org/freedesktop/PolicyKit1/Authority
             invoked by name :1.2402
             serial 25
       ========================================================================
       GDBus-debug:Return:
        >>>> METHOD RETURN
             in response to org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
             on object /org/freedesktop/PolicyKit1/Authority
             to name :1.2402
             reply-serial 25
      Signed-off-by: 's avatarDavid Zeuthen <davidz@redhat.com>
      d52e1c33
  16. 07 Jul, 2010 1 commit
  17. 06 Jul, 2010 1 commit
    • David Zeuthen's avatar
      GDBus: Handle autolaunching on UNIX/Freedesktop OSes · aab6d9ed
      David Zeuthen authored
      Also add a 'address' G_DBUS_DEBUG option that will print out useful
      debug information such as
      
        GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
        GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
        GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
        GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
        GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
        GDBus-debug:Address: dbus-launch output:
          0000: 75 6e 69 78  3a 61 62 73  74 72 61 63  74 3d 2f 74    unix:abstract=/t
          0010: 6d 70 2f 64  62 75 73 2d  77 42 41 6f  4b 59 49 52    mp/dbus-wBAoKYIR
          0020: 7a 75 2c 67  75 69 64 3d  30 34 30 64  31 33 66 33    zu,guid=040d13f3
          0030: 30 61 30 62  35 32 63 32  30 66 36 32  63 34 31 63    0a0b52c20f62c41c
          0040: 30 30 30 30  35 30 38 64  00 d2 38 00  00 01 00 40    0000508d..8....@
          0050: 05 00 00 00  00                                       .....
        GDBus-debug:Address: dbus-launch stderr output:
        14542: Autolaunch enabled (using X11).
        14542: --exit-with-session automatically enabled
        14542: Connected to X11 display ':0.0'
        14542: === Parent dbus-launch continues
        14542: Waiting for babysitter's intermediate parent
        14542: Reading address from bus
        14542: Reading PID from daemon
        14542: Saving x11 address
        14542: Created window 88080385
        14542: session file: /root/.dbus/session-bus/05e508961149264c9b750a4c494aa6f7-0
        14542: dbus-launch exiting
        GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'
      
      and
      
        GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
        GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
        GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
        GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
        GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
        GDBus-debug:Address: dbus-launch output:
          0000: 75 6e 69 78  3a 61 62 73  74 72 61 63  74 3d 2f 74    unix:abstract=/t
          0010: 6d 70 2f 64  62 75 73 2d  77 42 41 6f  4b 59 49 52    mp/dbus-wBAoKYIR
          0020: 7a 75 2c 67  75 69 64 3d  30 34 30 64  31 33 66 33    zu,guid=040d13f3
          0030: 30 61 30 62  35 32 63 32  30 66 36 32  63 34 31 63    0a0b52c20f62c41c
          0040: 30 30 30 30  35 30 38 64  00 d2 38 00  00 01 00 40    0000508d..8....@
          0050: 05 00 00 00  00                                       .....
        GDBus-debug:Address: dbus-launch stderr output:
        14549: Autolaunch enabled (using X11).
        14549: --exit-with-session automatically enabled
        14549: Connected to X11 display ':0.0'
        14549: dbus-daemon is already running. Returning existing parameters.
        14549: dbus-launch exiting
        GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'
      
      Note that things work exactly like libdbus, e.g. from the
      dbus-launch(1) man page:
      
        Whenever an autolaunch occurs, the application that had to start a
        new bus will be in its own little world; it can effectively end up
        starting a whole new session if it tries to use a lot of bus
        services. This can be suboptimal or even totally broken, depending
        on the app and what it tries to do.
      
        [...]
      
        You can always avoid autolaunch by manually setting
        DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default
        address if none is set is "autolaunch:", so if any other address is
        set there will be no autolaunch. You can however include autolaunch
        in an explicit session bus address as a fallback, for example
        DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if
        the first address doesn't work, processes will autolaunch. (The bus
        address variable contains a comma-separated list of addresses to
        try.)
      Signed-off-by: 's avatarDavid Zeuthen <davidz@redhat.com>
      aab6d9ed
  18. 01 Jul, 2010 1 commit
  19. 30 Jun, 2010 1 commit
  20. 21 Jun, 2010 1 commit
  21. 17 Jun, 2010 1 commit
    • David Zeuthen's avatar
      GDBusMessage: Fix bug when deserializing a message · 79d32c2f
      David Zeuthen authored
      See https://bugzilla.gnome.org/show_bug.cgi?id=621838 for the whole
      story. The problem was that we ended up reading data from arrays of
      arrays when we were just supposed to be aligning the buffers.
      
      Also add a host of debug infrastructure that was needed to find the
      root cause. For now it can be turned on only via defining
      DEBUG_SERIALIZER. In the future we might want to make it work via
      G_DBUS_DEBUG. In a nutshell, the added debug info looks like this
      
      Parsing blob (blob_len = 0x0084 bytes)
        0000: 6c 01 00 01  3c 00 00 00  41 00 00 00  37 00 00 00    l...<...A...7...
        0010: 08 01 67 00  08 61 61 79  61 7b 73 76  7d 00 00 00    ..g..aaya{sv}...
        0020: 01 01 6f 00  08 00 00 00  2f 66 6f 6f  2f 62 61 72    ..o...../foo/bar
        0030: 00 00 00 00  00 00 00 00  03 01 73 00  06 00 00 00    ..........s.....
        0040: 4d 65 6d 62  65 72 00 00  00 00 00 00  34 00 00 00    Member......4...
        0050: 03 00 00 00  63 77 64 00  01 73 00 00  23 00 00 00    ....cwd..s..#...
        0060: 2f 68 6f 6d  65 2f 64 61  76 69 64 7a  2f 48 61 63    /home/davidz/Hac
        0070: 6b 69 6e 67  2f 67 6c 69  62 2f 67 69  6f 2f 74 65    king/glib/gio/te
        0080: 73 74 73 00                                           sts.
      
      Parsing headers (blob_len = 0x0084 bytes)
        Reading type a{yv} from offset 0x000c: array spans 0x0037 bytes
          Reading type {yv} from offset 0x0010
            Reading type y from offset 0x0010: 0x08 '
            Reading type v from offset 0x0011
              Reading type g from offset 0x0014: 'aaya{sv}'
          Reading type {yv} from offset 0x001e
            Reading type y from offset 0x0020: 0x01 ''
            Reading type v from offset 0x0021
              Reading type o from offset 0x0024: '/foo/bar'
          Reading type {yv} from offset 0x0031
            Reading type y from offset 0x0038: 0x03 ''
            Reading type v from offset 0x0039
              Reading type s from offset 0x003c: 'Member'
      Parsing body (blob_len = 0x0084 bytes)
        Reading type (aaya{sv}) from offset 0x0047
          Reading type aay from offset 0x0048: array spans 0x0000 bytes
          Reading type a{sv} from offset 0x004c: array spans 0x0034 bytes
            Reading type {sv} from offset 0x0050
              Reading type s from offset 0x0050: 'cwd'
              Reading type v from offset 0x0058
                Reading type s from offset 0x005b: '/home/davidz/Hacking/glib/gio/tests'
      OK
      Signed-off-by: 's avatarDavid Zeuthen <davidz@redhat.com>
      79d32c2f
  22. 24 May, 2010 1 commit
    • Allison Karlitskaya's avatar
      GDBusConnection.call(): add 'reply_type' argument · 3160bcad
      Allison Karlitskaya authored
      This allows the caller to specify the reply type that they are expecting
      for this call.  If the reply comes back with the wrong type, GDBus will
      generate an appropriate error internally.
      
        - add a GVariantType * argument to g_dbus_connection_call() and
          _call_sync().
      
        - move the internal API for computing message types from introspection
          data to be based on GVariantType instead of strings.  Update users
          of this code.
      
        - have GDBusProxy pass this calculated GVariantType into
          g_dbus_connection_call().  Remove the checks done in GDBusProxy.
      
        - Update other users of the code (test cases, gdbus-tool, GSettings
          tool, etc).  In some cases, remove redundant checks; in some other
          cases, we are fixing bugs because no checking was done where it
          should have been.
      
      Closes bug #619391.
      3160bcad
  23. 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: 's avatarDavid Zeuthen <davidz@redhat.com>
      366b3ffc
  24. 09 May, 2010 1 commit
  25. 06 May, 2010 1 commit