1. 18 Aug, 2010 10 commits
  2. 17 Aug, 2010 10 commits
    • Dan Winship's avatar
      update gio/tests/.gitignore · ddad707b
      Dan Winship authored
      ddad707b
    • Christian Persch's avatar
      Plug a mem leak in GDBusWorker · c5637926
      Christian Persch authored
      Free the read buffer.
      
      ==26538== 4,096 bytes in 1 blocks are definitely lost in loss record 781 of 781
      ==26538==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
      ==26538==    by 0x4005C66: realloc (vg_replace_malloc.c:476)
      ==26538==    by 0x405244D: g_realloc (gmem.c:181)
      ==26538==    by 0x420E066: _g_dbus_worker_do_read_unlocked (gdbusprivate.c:780)
      ==26538==    by 0x420E1D1: _g_dbus_worker_do_read (gdbusprivate.c:812)
      ==26538==    by 0x420F14A: _g_dbus_worker_thread_begin_func (gdbusprivate.c:1318)
      ==26538==    by 0x420D2ED: invoke_caller (gdbusprivate.c:266)
      ==26538==    by 0x404DA7C: g_idle_dispatch (gmain.c:4224)
      ==26538==    by 0x4049FCD: g_main_dispatch (gmain.c:2119)
      ==26538==    by 0x404B2C1: g_main_context_dispatch (gmain.c:2672)
      ==26538==    by 0x404B716: g_main_context_iterate (gmain.c:2750)
      ==26538==    by 0x404BE7F: g_main_loop_run (gmain.c:2958)
      ==26538==    by 0x420D2B5: shared_thread_func (gdbusprivate.c:248)
      ==26538==    by 0x4077958: g_thread_create_proxy (gthread.c:1897)
      ==26538==    by 0x57D918: start_thread (pthread_create.c:301)
      ==26538==    by 0x4C6CBD: clone (clone.S:133)
      
      Bug #627187.
      c5637926
    • Christian Persch's avatar
      Plug a mem leak in gdbus-connection test · a91a4a42
      Christian Persch authored
      ==26538== 145 (24 direct, 121 indirect) bytes in 1 blocks are definitely lost in loss record 765 of 790
      ==26538==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
      ==26538==    by 0x405233C: g_malloc (gmem.c:134)
      ==26538==    by 0x406A57E: g_slice_alloc (gslice.c:836)
      ==26538==    by 0x406A60C: g_slice_copy (gslice.c:858)
      ==26538==    by 0x4035C5A: g_error_copy (gerror.c:160)
      ==26538==    by 0x41B6387: g_simple_async_result_set_from_error (gsimpleasyncresult.c:638)
      ==26538==    by 0x41FCDEB: g_dbus_connection_call_done (gdbusconnection.c:4808)
      ==26538==    by 0x41B682E: g_simple_async_result_complete (gsimpleasyncresult.c:762)
      ==26538==    by 0x41B686A: complete_in_idle_cb (gsimpleasyncresult.c:772)
      ==26538==    by 0x404DA7C: g_idle_dispatch (gmain.c:4224)
      ==26538==    by 0x4049FCD: g_main_dispatch (gmain.c:2119)
      ==26538==    by 0x404B2C1: g_main_context_dispatch (gmain.c:2672)
      ==26538==    by 0x404B716: g_main_context_iterate (gmain.c:2750)
      ==26538==    by 0x404BE7F: g_main_loop_run (gmain.c:2958)
      ==26538==    by 0x804B5CC: test_connection_send (gdbus-connection.c:407)
      ==26538==    by 0x4073D04: test_case_run (gtestutils.c:1174)
      
      Bug #627187.
      a91a4a42
    • Christian Persch's avatar
      Plug a mem leak in gdbus-connection test · 75563e81
      Christian Persch authored
      ==25403== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 603 of 787
      ==25403==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
      ==25403==    by 0x405233C: g_malloc (gmem.c:134)
      ==25403==    by 0x406A57E: g_slice_alloc (gslice.c:836)
      ==25403==    by 0x406A5C3: g_slice_alloc0 (gslice.c:848)
      ==25403==    by 0x4035B4E: g_error_new_literal (gerror.c:117)
      ==25403==    by 0x4035ED9: g_set_error_literal (gerror.c:314)
      ==25403==    by 0x41F6434: g_dbus_connection_close_sync (gdbusconnection.c:1284)
      ==25403==    by 0x804A861: test_connection_life_cycle (gdbus-connection.c:158)
      ==25403==    by 0x4073D04: test_case_run (gtestutils.c:1174)
      ==25403==    by 0x4073FC2: g_test_run_suite_internal (gtestutils.c:1223)
      ==25403==    by 0x4074077: g_test_run_suite_internal (gtestutils.c:1233)
      ==25403==    by 0x4074077: g_test_run_suite_internal (gtestutils.c:1233)
      ==25403==    by 0x40741FB: g_test_run_suite (gtestutils.c:1274)
      ==25403==    by 0x40733E5: g_test_run (gtestutils.c:877)
      ==25403==    by 0x804DC92: main (gdbus-connection.c:1024)
      
      Bug #627187.
      75563e81
    • Christian Persch's avatar
      Plug a mem leak in the gdbus-connection test · a62a2fd8
      Christian Persch authored
      Bug #627182.
      a62a2fd8
    • Christian Persch's avatar
      Use g_memory_output_stream_steal_data here · 7191fc3f
      Christian Persch authored
      ... instead of one extra g_memdup().
      
      Bug #627181.
      7191fc3f
    • Christian Persch's avatar
      Use G_DEFINE_[BOXED|POINTER]_TYPE instead of handwritten code · 71e73ffd
      Christian Persch authored
      Now that we have convenience macros to implement boxed and pointer
      types, use them.
      71e73ffd
    • Christian Persch's avatar
      Add G_DEFINE_{BOXED,POINTER}_TYPE[_WITH_CODE] · dc199931
      Christian Persch authored
      Add convenience type definition macros for boxed and pointer types
      similar to G_DEFINE_TYPE for object types. Bug #449565.
      dc199931
    • Christian Persch's avatar
      Add GZIP header processing to GZlibCompressor/GZlibDecompressor · cae86073
      Christian Persch authored
      Add GZlibCompressor:file-info property. If it contains a non-NULL
      GFileInfo, and the compressor is in GZIP mode, the filename and
      modification time from the file info are written to the GZIP header
      in the output data.
      
      Add GZlibDeompressor:file-info property. If the decompressor is in GZIP
      mode, and the GZIP data contains a GZIP header, the filename and
      modification time are read from it, stored in a GFileInfo, and the
      file-info property is notified.
      
      Bug #617691.
      cae86073
    • Christian Persch's avatar
      Add g_memory_output_stream_steal_data · b196cd74
      Christian Persch authored
      Bug #622184.
      b196cd74
  3. 16 Aug, 2010 10 commits
    • Matthias Clasen's avatar
      Bump version · 322ac7ff
      Matthias Clasen authored
      322ac7ff
    • Matthias Clasen's avatar
      Fix a typo · 503b0744
      Matthias Clasen authored
      503b0744
    • David Zeuthen's avatar
      Add NEWS item for bug 627071 · e21e44fc
      David Zeuthen authored
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      e21e44fc
    • David Zeuthen's avatar
      Bug 627071 – g_output_stream_write() clarification · b8e7ef6e
      David Zeuthen authored
      This patch guarantees that g_output_stream_write() can never fail with
      G_IO_ERROR_WOULD_BLOCK. Without such a guarantee, we would need some
      kind of GIOPollable interface or some way to get an event when the
      stream is writable again. Which is mostly useless considering that
      this method is asynchronous anyway.
      
      Note: this patch just codifies existing behavior - GUnixOutputStream,
      GSocketOutputStream and other implementations already work this way.
      
      See also bug 626748 comment 5 for how the GDBus code relies on this
      guarantee.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=627071Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      b8e7ef6e
    • Matthias Clasen's avatar
      More NEWS · 28517063
      Matthias Clasen authored
      28517063
    • Matthias Clasen's avatar
      Fix a doc format issue · 789c0cc8
      Matthias Clasen authored
      789c0cc8
    • Matthias Clasen's avatar
      Update NEWS for 2.25.14 · d848a5ea
      Matthias Clasen authored
      d848a5ea
    • 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
    • David Zeuthen's avatar
      GSocket: Properly initialize msg.msg_control · a6264a3a
      David Zeuthen authored
      This patch fixes this problem
      
         Syscall param socketcall.sendmsg(msg.msg_control) points to uninitialised byte(s)
            at 0x3D5B00EA60: __sendmsg_nocancel (syscall-template.S:82)
            by 0x53F9790: g_socket_send_message (gsocket.c:2918)
            by 0x540FDD0: g_unix_connection_send_credentials (gunixconnection.c:351)
            by 0x542B93F: _g_dbus_auth_run_client (gdbusauth.c:618)
            by 0x5438001: initable_init (gdbusconnection.c:2191)
            by 0x53E09CC: g_initable_init (ginitable.c:105)
            by 0x543F6E9: g_bus_get_sync (gdbusconnection.c:6091)
            by 0x402C7E: test_connection_life_cycle (gdbus-connection.c:126)
            by 0x4C7CABB: test_case_run (gtestutils.c:1174)
            by 0x4C7CD84: g_test_run_suite_internal (gtestutils.c:1223)
            by 0x4C7CE49: g_test_run_suite_internal (gtestutils.c:1233)
            by 0x4C7CE49: g_test_run_suite_internal (gtestutils.c:1233)
          Address 0x7fefff9fc is on thread 1's stack
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      a6264a3a
    • Matthias Clasen's avatar
      Declare stream base classes as abstract · 4bc4590c
      Matthias Clasen authored
      4bc4590c
  4. 15 Aug, 2010 2 commits
  5. 14 Aug, 2010 8 commits