Commit Graph

1714 Commits

Author SHA1 Message Date
Christian Persch
5de1bf4a91 Plug a mem leak in the gdbus-proxy test
==23341== 85 (24 direct, 61 indirect) bytes in 1 blocks are definitely lost in loss record 900 of 971
==23341==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23341==    by 0x4057094: g_malloc (gmem.c:134)
==23341==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==23341==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==23341==    by 0x403A751: g_error_new_valist (gerror.c:54)
==23341==    by 0x403AAD4: g_set_error (gerror.c:240)
==23341==    by 0x420B807: decode_method_reply (gdbusconnection.c:4774)
==23341==    by 0x420C2BA: g_dbus_connection_call_sync (gdbusconnection.c:5188)
==23341==    by 0x421B7C9: g_dbus_proxy_call_sync (gdbusproxy.c:2477)
==23341==    by 0x804BD89: test_bogus_method_return (gdbus-proxy.c:430)

Bug #628331.
2010-09-03 16:04:29 -04:00
Christian Persch
be33ef85d0 Plug some mem leaks in gdbus-peer test
==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.
2010-09-03 16:03:48 -04:00
Christian Persch
3df5866139 Plug a mem leak in the gdbus-peer test
==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.
2010-09-03 16:02:11 -04:00
Christian Persch
bd2faedefd Plug a mem leak in network-address test
==4616== 46 (32 direct, 14 indirect) bytes in 1 blocks are definitely lost in loss record 193 of 305
==4616==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==4616==    by 0x4057094: g_malloc (gmem.c:134)
==4616==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==4616==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==4616==    by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==4616==    by 0x412372A: g_object_constructor (gobject.c:1482)
==4616==    by 0x4123147: g_object_newv (gobject.c:1347)
==4616==    by 0x41236BB: g_object_new_valist (gobject.c:1463)
==4616==    by 0x4122BB4: g_object_new (gobject.c:1181)
==4616==    by 0x41B2D0F: g_network_address_new (gnetworkaddress.c:262)
==4616==    by 0x8048A70: test_basic (network-address.c:10)

Bug #628331.
2010-09-03 16:01:10 -04:00
Christian Persch
fa6937603c Plug a mem leak in contexts test
==14059== 96 bytes in 2 blocks are definitely lost in loss record 520 of 543
==14059==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==14059==    by 0x4057094: g_malloc (gmem.c:134)
==14059==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==14059==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==14059==    by 0x41385BB: g_type_create_instance (gtype.c:1867)
==14059==    by 0x411E72A: g_object_constructor (gobject.c:1482)
==14059==    by 0x411DE1D: g_object_newv (gobject.c:1266)
==14059==    by 0x411DB93: g_object_new (gobject.c:1178)
==14059==    by 0x42296AF: _g_local_file_input_stream_new (glocalfileinputstream.c:152)
==14059==    by 0x422281F: g_local_file_read (glocalfile.c:1322)
==14059==    by 0x418A8A9: open_read_async_thread (gfile.c:5050)
==14059==    by 0x41B71BB: run_in_thread (gsimpleasyncresult.c:853)
==14059==    by 0x41A5FBC: io_job_thread (gioscheduler.c:181)
==14059==    by 0x407DCDE: g_thread_pool_thread_proxy (gthreadpool.c:314)
==14059==    by 0x407C6B0: g_thread_create_proxy (gthread.c:1897)
==14059==    by 0x57D918: start_thread (pthread_create.c:301)
==14059==    by 0x4C6CBD: clone (clone.S:133)

Bug #628331.
2010-09-03 16:00:15 -04:00
Christian Persch
60349ecc4d Plug mem leaks in contexts test
==2464== 80 (16 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 515 of 547
==2464==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2464==    by 0x4057094: g_malloc (gmem.c:134)
==2464==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2464==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2464==    by 0x41385BB: g_type_create_instance (gtype.c:1867)
==2464==    by 0x411E72A: g_object_constructor (gobject.c:1482)
==2464==    by 0x411DE1D: g_object_newv (gobject.c:1266)
==2464==    by 0x411DB93: g_object_new (gobject.c:1178)
==2464==    by 0x4220D74: _g_local_file_new (glocalfile.c:310)
==2464==    by 0x422C897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2464==    by 0x41CA91C: g_vfs_get_file_for_path (gvfs.c:94)
==2464==    by 0x418C1B6: g_file_new_for_path (gfile.c:5898)
==2464==    by 0x8049509: test1_thread (contexts.c:110)

==2464== 80 (16 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 516 of 547
==2464==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2464==    by 0x4057094: g_malloc (gmem.c:134)
==2464==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2464==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2464==    by 0x41385BB: g_type_create_instance (gtype.c:1867)
==2464==    by 0x411E72A: g_object_constructor (gobject.c:1482)
==2464==    by 0x411DE1D: g_object_newv (gobject.c:1266)
==2464==    by 0x411DB93: g_object_new (gobject.c:1178)
==2464==    by 0x4220D74: _g_local_file_new (glocalfile.c:310)
==2464==    by 0x422C897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2464==    by 0x41CA91C: g_vfs_get_file_for_path (gvfs.c:94)
==2464==    by 0x418C1B6: g_file_new_for_path (gfile.c:5898)
==2464==    by 0x804964D: test_context_independence (contexts.c:144)

Bug #628331.
2010-09-03 15:58:51 -04:00
Christian Persch
e4a6b1dcdc Plug a mem leak in buffered-input-stream test
==2429== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 276 of 355
==2429==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2429==    by 0x4057094: g_malloc (gmem.c:134)
==2429==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2429==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2429==    by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2429==    by 0x403AC31: g_set_error_literal (gerror.c:314)
==2429==    by 0x4175525: g_buffered_input_stream_read_byte (gbufferedinputstream.c:880)
==2429==    by 0x804A21A: test_read_byte (buffered-input-stream.c:153)

Bug #628331.
2010-09-03 15:57:26 -04:00
Christian Persch
01a19dee68 Plug a mem leak in g-icon test
==2428== 256 bytes in 1 blocks are definitely lost in loss record 591 of 604
==2428==    at 0x4005CD2: realloc (vg_replace_malloc.c:476)
==2428==    by 0x40571A5: g_realloc (gmem.c:181)
==2428==    by 0x4075287: g_string_maybe_expand (gstring.c:395)
==2428==    by 0x40760D8: g_string_insert_c (gstring.c:1049)
==2428==    by 0x4074D41: g_string_append_c_inline (gstring.h:153)
==2428==    by 0x4075B3C: g_string_append_uri_escaped (gstring.c:822)
==2428==    by 0x41A46AC: g_icon_to_string_tokenized (gicon.c:164)
==2428==    by 0x41A498F: g_icon_to_string (gicon.c:252)
==2428==    by 0x8049E1A: test_g_icon_serialize (g-icon.c:222)

Bug #628331.
2010-09-03 15:56:23 -04:00
Christian Persch
e8bdd2cb7a Plug a huge mem leak in data-output-stream test
==12763== 16,777,215 bytes in 1 blocks are possibly lost in loss record 357 of 357
==12763==    at 0x4004F1B: calloc (vg_replace_malloc.c:418)
==12763==    by 0x405711D: g_malloc0 (gmem.c:157)
==12763==    by 0x8048ED6: test_basic (data-output-stream.c:40)

Bug #628331.
2010-09-03 15:55:10 -04:00
Christian Persch
05d6fcf88c Plug a mem leak in data-output-stream test
==2426== 45,034 bytes in 4,094 blocks are definitely lost in loss record 358 of 361
==2426==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2426==    by 0x4057094: g_malloc (gmem.c:134)
==2426==    by 0x40573DB: g_malloc_n (gmem.c:281)
==2426==    by 0x4071ABD: g_strconcat (gstrfuncs.c:315)
==2426==    by 0x804916A: test_read_lines (data-output-stream.c:83)

Bug #628331.
2010-09-03 15:53:56 -04:00
Christian Persch
45331a4640 Plug a mem leak in data-input-stream test
==12351== 45,045 bytes in 4,095 blocks are definitely lost in loss record 377 of 380
==12351==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==12351==    by 0x4057094: g_malloc (gmem.c:134)
==12351==    by 0x40573DB: g_malloc_n (gmem.c:281)
==12351==    by 0x4071ABD: g_strconcat (gstrfuncs.c:315)
==12351==    by 0x8049811: test_read_lines (data-input-stream.c:99)

Bug #628331.
2010-09-03 15:53:05 -04:00
Christian Persch
36c7d95c9c Plug a mem leak in data-input-stream test
==2415== 45,045 bytes in 4,095 blocks are definitely lost in loss record 393 of 399
==2415==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2415==    by 0x4057094: g_malloc (gmem.c:134)
==2415==    by 0x417FC29: g_data_input_stream_read_line (gdatainputstream.c:797)
==2415==    by 0x8049874: test_read_lines (data-input-stream.c:111)

==12088== 360 bytes in 40 blocks are definitely lost in loss record 368 of 381
==12088==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==12088==    by 0x4057094: g_malloc (gmem.c:134)
==12088==    by 0x417FF4C: g_data_input_stream_read_until (gdatainputstream.c:914)
==12088==    by 0x8049B6F: test_read_until (data-input-stream.c:182)

Bug #628331.
2010-09-03 15:47:38 -04:00
Christian Persch
91e3803596 Plug a mem leak in data-input-stream test
==2415== 165 (72 direct, 93 indirect) bytes in 3 blocks are definitely lost in loss record 373 of 399
==2415==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2415==    by 0x4057094: g_malloc (gmem.c:134)
==2415==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2415==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2415==    by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2415==    by 0x403AC31: g_set_error_literal (gerror.c:314)
==2415==    by 0x417ED29: read_data (gdatainputstream.c:309)
==2415==    by 0x417EE9D: g_data_input_stream_read_byte (gdatainputstream.c:344)
==2415==    by 0x8049DEC: test_data_array (data-input-stream.c:263)

Bug #628331.
2010-09-03 15:45:48 -04:00
Christian Persch
31b15451cf Plug a mem leak in readwrite test
==10395== 80 (24 direct, 56 indirect) bytes in 1 blocks are definitely lost in loss record 529 of 561
==10395==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==10395==    by 0x4057094: g_malloc (gmem.c:134)
==10395==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==10395==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==10395==    by 0x403A751: g_error_new_valist (gerror.c:54)
==10395==    by 0x403AAD4: g_set_error (gerror.c:240)
==10395==    by 0x4230328: _g_local_file_output_stream_create (glocalfileoutputstream.c:628)
==10395==    by 0x4227A04: g_local_file_create_readwrite (glocalfile.c:1388)
==10395==    by 0x418974C: g_file_create_readwrite (gfile.c:1784)
==10395==    by 0x8049FCD: test_g_file_create_readwrite (readwrite.c:187)

Bug #628331.
2010-09-03 15:44:28 -04:00
Christian Persch
94102a40f7 Plug some huge mem leaks in converter-stream test
==8564== 24,000,000 bytes in 6 blocks are possibly lost in loss record 592 of 594
==8564==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==8564==    by 0x4057094: g_malloc (gmem.c:134)
==8564==    by 0x804AA37: test_corruption (converter-stream.c:589)
==8564==    by 0x804B05B: test_roundtrip (converter-stream.c:652)

==9459== 25,165,824 bytes in 6 blocks are possibly lost in loss record 593 of 594
==9459==    at 0x4005CD2: realloc (vg_replace_malloc.c:476)
==9459==    by 0x40571A5: g_realloc (gmem.c:181)
==9459==    by 0x41B08A3: array_resize (gmemoryoutputstream.c:501)
==9459==    by 0x41B0A5D: g_memory_output_stream_write (gmemoryoutputstream.c:578)
==9459==    by 0x41B57EF: g_output_stream_write (goutputstream.c:216)
==9459==    by 0x41B591B: g_output_stream_write_all (goutputstream.c:268)
==9459==    by 0x417D617: flush_buffer (gconverteroutputstream.c:359)
==9459==    by 0x417D958: g_converter_output_stream_write (gconverteroutputstream.c:502)
==9459==    by 0x41B5D7F: g_output_stream_real_splice (goutputstream.c:428)
==9459==    by 0x41B5C6C: g_output_stream_splice (goutputstream.c:380)
==9459==    by 0x804AB10: test_corruption (converter-stream.c:600)

==9785== 25,165,824 bytes in 6 blocks are possibly lost in loss record 592 of 592
==9785==    at 0x4005CD2: realloc (vg_replace_malloc.c:476)
==9785==    by 0x40571A5: g_realloc (gmem.c:181)
==9785==    by 0x41B08A3: array_resize (gmemoryoutputstream.c:501)
==9785==    by 0x41B0A5D: g_memory_output_stream_write (gmemoryoutputstream.c:578)
==9785==    by 0x41B5D7F: g_output_stream_real_splice (goutputstream.c:428)
==9785==    by 0x41B5C6C: g_output_stream_splice (goutputstream.c:380)
==9785==    by 0x804ADF1: test_corruption (converter-stream.c:622)
==9785==    by 0x804B06C: test_roundtrip (converter-stream.c:652)

Bug #628331.
2010-09-03 15:43:03 -04:00
Christian Persch
24bee1a130 Plug a mem leak in convert-stream test
==7540== 487 (64 direct, 423 indirect) bytes in 2 blocks are definitely lost in loss record 597 of 615
==7540==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==7540==    by 0x4057094: g_malloc (gmem.c:134)
==7540==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==7540==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==7540==    by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==7540==    by 0x412372A: g_object_constructor (gobject.c:1482)
==7540==    by 0x4123147: g_object_newv (gobject.c:1347)
==7540==    by 0x41236BB: g_object_new_valist (gobject.c:1463)
==7540==    by 0x41A756E: g_initable_new_valist (ginitable.c:214)
==7540==    by 0x41A743E: g_initable_new (ginitable.c:138)
==7540==    by 0x417B67A: g_charset_converter_new (gcharsetconverter.c:215)
==7540==    by 0x804B043: test_charset (converter-stream.c:675)

Bug #628331.
2010-09-03 15:40:55 -04:00
Christian Persch
ac8600a14b Plug a mem leak in converter-stream test
==2396== 168 (92 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 598 of 625
==2396==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2396==    by 0x4057094: g_malloc (gmem.c:134)
==2396==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2396==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2396==    by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2396==    by 0x412372A: g_object_constructor (gobject.c:1482)
==2396==    by 0x4123147: g_object_newv (gobject.c:1347)
==2396==    by 0x41236BB: g_object_new_valist (gobject.c:1463)
==2396==    by 0x4122BB4: g_object_new (gobject.c:1181)
==2396==    by 0x417C54D: g_converter_input_stream_new (gconverterinputstream.c:204)
==2396==    by 0x804A53E: test_compressor (converter-stream.c:484)

Bug #628331.
2010-09-03 15:39:58 -04:00
Christian Persch
85179745ac Plug a mem leak in converter-stream test
==2396== 66 (24 direct, 42 indirect) bytes in 1 blocks are definitely lost in loss record 565 of 625
==2396==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2396==    by 0x4057094: g_malloc (gmem.c:134)
==2396==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2396==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2396==    by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2396==    by 0x403AC31: g_set_error_literal (gerror.c:314)
==2396==    by 0x417BA38: g_charset_converter_convert (gcharsetconverter.c:344)
==2396==    by 0x417BF67: g_converter_convert (gconverter.c:174)
==2396==    by 0x417C9EB: g_converter_input_stream_read (gconverterinputstream.c:403)
==2396==    by 0x41A7A17: g_input_stream_read (ginputstream.c:204)
==2396==    by 0x41A7B43: g_input_stream_read_all (ginputstream.c:256)
==2396==    by 0x804B0E4: test_charset (converter-stream.c:682)

Bug #628331.
2010-09-03 15:39:07 -04:00
Christian Persch
7ec414229b Plug a mem leak in converter-stream test
==2396== 39 (24 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 398 of 625
==2396==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2396==    by 0x4057094: g_malloc (gmem.c:134)
==2396==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2396==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2396==    by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2396==    by 0x403AC31: g_set_error_literal (gerror.c:314)
==2396==    by 0x80498F7: g_compressor_converter_convert (converter-stream.c:244)
==2396==    by 0x417BF67: g_converter_convert (gconverter.c:174)
==2396==    by 0x417CBDE: g_converter_input_stream_read (gconverterinputstream.c:460)
==2396==    by 0x41A7A17: g_input_stream_read (ginputstream.c:204)
==2396==    by 0x804A832: test_compressor (converter-stream.c:545)

Bug #628331.
2010-09-03 15:37:56 -04:00
Christian Persch
d5d277dccf Plug a mem leak in g-file-info test
==2395== 64 bytes in 1 blocks are definitely lost in loss record 381 of 407
==2395==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2395==    by 0x4005C66: realloc (vg_replace_malloc.c:476)
==2395==    by 0x40571A5: g_realloc (gmem.c:181)
==2395==    by 0x401D670: g_ptr_array_maybe_expand (garray.c:968)
==2395==    by 0x401DD0B: g_ptr_array_add (garray.c:1225)
==2395==    by 0x4199AA9: g_file_info_list_attributes (gfileinfo.c:646)
==2395==    by 0x80491CE: test_g_file_info (g-file-info.c:76)

==2395== 132 (64 direct, 68 indirect) bytes in 1 blocks are definitely lost in loss record 396 of 407
==2395==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2395==    by 0x4005C66: realloc (vg_replace_malloc.c:476)
==2395==    by 0x40571A5: g_realloc (gmem.c:181)
==2395==    by 0x401D670: g_ptr_array_maybe_expand (garray.c:968)
==2395==    by 0x401DD0B: g_ptr_array_add (garray.c:1225)
==2395==    by 0x4199A82: g_file_info_list_attributes (gfileinfo.c:642)
==2395==    by 0x80492B7: test_g_file_info (g-file-info.c:86)

Bug #628331.
2010-09-03 15:37:08 -04:00
Christian Persch
35e101fa0a Plug a mem leak in the readwrite test
And use g_assert_[no_]error().

==2392== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 451 of 573
==2392==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392==    by 0x4057094: g_malloc (gmem.c:134)
==2392==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392==    by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2392==    by 0x403AC31: g_set_error_literal (gerror.c:314)
==2392==    by 0x41B7619: g_output_stream_set_pending (goutputstream.c:1198)
==2392==    by 0x41B5799: g_output_stream_write (goutputstream.c:210)
==2392==    by 0x41B590B: g_output_stream_write_all (goutputstream.c:268)
==2392==    by 0x8049B54: verify_iostream (readwrite.c:110)

Bug #628331.
2010-09-03 15:35:44 -04:00
Christian Persch
93d85ade57 Plug a mem leak in the readwrite test
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 369 of 573
==2392==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392==    by 0x4057094: g_malloc (gmem.c:134)
==2392==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392==    by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392==    by 0x412372A: g_object_constructor (gobject.c:1482)
==2392==    by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392==    by 0x4122B93: g_object_new (gobject.c:1178)
==2392==    by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392==    by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392==    by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392==    by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392==    by 0x804A2B9: test_g_file_replace_readwrite (readwrite.c:235)

Bug #628331.
2010-09-03 15:34:12 -04:00
Christian Persch
9fba7a43be Plug a mem leak in the readwrite test
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 368 of 573
==2392==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392==    by 0x4057094: g_malloc (gmem.c:134)
==2392==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392==    by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392==    by 0x412372A: g_object_constructor (gobject.c:1482)
==2392==    by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392==    by 0x4122B93: g_object_new (gobject.c:1178)
==2392==    by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392==    by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392==    by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392==    by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392==    by 0x8049F23: test_g_file_create_readwrite (readwrite.c:183)

Bug #628331.
2010-09-03 15:33:28 -04:00
Christian Persch
e481bf8bf6 Plug a mem leak in the readwrite test
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 367 of 573
==2392==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392==    by 0x4057094: g_malloc (gmem.c:134)
==2392==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392==    by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392==    by 0x412372A: g_object_constructor (gobject.c:1482)
==2392==    by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392==    by 0x4122B93: g_object_new (gobject.c:1178)
==2392==    by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392==    by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392==    by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392==    by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392==    by 0x8049E30: test_g_file_open_readwrite (readwrite.c:153)

Bug #628331.
2010-09-03 15:32:32 -04:00
Christian Persch
689b054b6e Plug a mem leak in the memory-input-stream test
==2389== 84 (44 direct, 40 indirect) bytes in 1 blocks are definitely lost in loss record 299 of 315
==2389==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2389==    by 0x4057094: g_malloc (gmem.c:134)
==2389==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2389==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2389==    by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2389==    by 0x412372A: g_object_constructor (gobject.c:1482)
==2389==    by 0x4122E1D: g_object_newv (gobject.c:1266)
==2389==    by 0x4122B93: g_object_new (gobject.c:1178)
==2389==    by 0x41AF54C: g_memory_input_stream_new (gmemoryinputstream.c:199)
==2389==    by 0x8048BD1: test_read_chunks (memory-input-stream.c:40)

Bug #628331.
2010-09-03 15:31:37 -04:00
Christian Persch
53ae72b926 Plug a mem leak in the memory-input-stream test
==2389== 59 (24 direct, 35 indirect) bytes in 1 blocks are definitely lost in loss record 290 of 315
==2389==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2389==    by 0x4057094: g_malloc (gmem.c:134)
==2389==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2389==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2389==    by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2389==    by 0x403AC31: g_set_error_literal (gerror.c:314)
==2389==    by 0x41AFD15: g_memory_input_stream_truncate (gmemoryinputstream.c:517)
==2389==    by 0x41BAC0F: g_seekable_truncate (gseekable.c:174)
==2389==    by 0x8049595: test_truncate (memory-input-stream.c:123)

Bug #628331.
2010-09-03 15:30:47 -04:00
Christian Persch
6320b04fe9 Plug a mem leak in gsettings test
==2530== 13 bytes in 1 blocks are definitely lost in loss record 373 of 681
==2530==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2530==    by 0x4057094: g_malloc (gmem.c:134)
==2530==    by 0x40573DB: g_malloc_n (gmem.c:281)
==2530==    by 0x40717FC: g_strdup (gstrfuncs.c:101)
==2530==    by 0x4147F56: value_lcopy_string (gvaluetypes.c:313)
==2530==    by 0x4123F0B: g_object_get_valist (gobject.c:1643)
==2530==    by 0x41240FF: g_object_get (gobject.c:1731)
==2530==    by 0x804A4BA: test_basic (gsettings.c:28)

Bug #628331.
2010-09-03 15:29:51 -04:00
Christian Persch
e8fc3ba3d0 Plug a mem leak
Don't leak the ptr arrays in the map_sender_unique_name_to_signal_data_array
hash table.

==23440== 84 (20 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 920 of 993
==23440==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23440==    by 0x4057094: g_malloc (gmem.c:134)
==23440==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==23440==    by 0x401D2D0: g_ptr_array_sized_new (garray.c:799)
==23440==    by 0x401D2AC: g_ptr_array_new (garray.c:783)
==23440==    by 0x420834A: g_dbus_connection_signal_subscribe (gdbusconnection.c:3084)

Bug #628436.
2010-09-03 15:19:22 -04:00
Christian Persch
8795f52aae Plug a mem leak
==31063== 98 (24 direct, 74 indirect) bytes in 1 blocks are definitely lost in loss record 946 of 1,136
==31063==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==31063==    by 0x4057094: g_malloc (gmem.c:134)
==31063==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==31063==    by 0x4092383: g_variant_get_child_value (gvariant-core.c:847)
==31063==    by 0x408BE9E: g_variant_get_variant (gvariant.c:709)
==31063==    by 0x40903F5: g_variant_valist_get_nnp (gvariant.c:3767)
==31063==    by 0x40907A9: g_variant_valist_get_leaf (gvariant.c:3884)
==31063==    by 0x4090D10: g_variant_valist_get (gvariant.c:4065)
==31063==    by 0x4090E59: g_variant_valist_get (gvariant.c:4100)
==31063==    by 0x40911B6: g_variant_get_va (gvariant.c:4296)
==31063==    by 0x40910BC: g_variant_get (gvariant.c:4248)
==31063==    by 0x4208DAF: invoke_set_property_in_idle_cb (gdbusconnection.c:3676)

Bug #628346.
2010-09-03 15:16:47 -04:00
Christian Persch
1f49f3fa34 Plug a mem leak
... and use g_error_matches().

==29535== 1,360 (408 direct, 952 indirect) bytes in 17 blocks are definitely lost in loss record 1,252 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 0x406F31B: g_slice_alloc0 (gslice.c:848)
==29535==    by 0x403A751: g_error_new_valist (gerror.c:54)
==29535==    by 0x403AAD4: g_set_error (gerror.c:240)
==29535==    by 0x41C06C8: g_socket_send_message (gsocket.c:2967)
==29535==    by 0x421CB64: write_message_continue_writing (gdbusprivate.c:958)
==29535==    by 0x421CE2A: write_message_async (gdbusprivate.c:1049)
==29535==    by 0x421D4DD: maybe_write_next_message (gdbusprivate.c:1291)
==29535==    by 0x421D26B: message_written (gdbusprivate.c:1187)
==29535==    by 0x421D322: write_message_cb (gdbusprivate.c:1216)

Bug #628345.
2010-09-03 15:03:24 -04:00
Tor Lillqvist
6ddef375c8 Recuce DLL hijack risk on Windows
Don't call LoadLibrary() on shell32.dll or kernel32.dll. kernel32.dll
is always loaded. Shell32.dll is also already loaded as glib links to
functions in it. So just call GetModuleHandle() on them.

For mlang.dll in win_iconv.c and winhttp.dll in gwinhttpvfs.c, always
try loading them from a complete path, from the Windows system
directory.

Use the "tool help" API to enumerate modules in gmodule-win32.c. It is
present in all Windows versions since Windows 2000, which is all we
support anyway. Thus no need to look that API up dynamically. Just
link to it normally. We can bin the fallback code that attempts to use
the psapi API.
2010-09-02 22:36:47 +03:00
Christian Persch
db0eaa299c Fix building with zlib < 1.2.4 on win32
The gzip header processing functions were only exported
since 1.2.4 on win32, so #ifdef this code accordingly.

Bug #628505.
2010-09-01 15:09:51 +02:00
Ryan Lortie
ed72dcdd45 Fix small bug in registry backend
'n' and 'q' types had their signed/unsigned meaning inverted.
2010-09-01 15:05:42 +02:00
Sam Thursfield
3209024c3b Add GSettings Windows Registry backend 2010-09-01 15:05:42 +02:00
Matthias Clasen
31a72dd719 Update symbol list 2010-08-30 19:31:45 -04:00
David Zeuthen
f4f45e980b GDBusProxy: remove superfluous -gdbus-proxy-method-name qdata
Looks like we're not using this anymore.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-30 13:58:41 -04:00
David Zeuthen
52348e1587 Bug 628324 – Invalid reads in gdbus-export test
Looks like we forgot to ref the returned GVariant in
g_dbus_proxy_call_finish().

It's a good question why code using g_dbus_proxy_call() and
g_dbus_proxy_call_finish() worked in the first place - probably the
answer is that no-one really used these APIs.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-30 13:51:43 -04:00
Ryan Lortie
846b0b3466 GAction is now an interface
the new class GSimpleAction is the implementation half
2010-08-30 19:26:37 +02:00
Ryan Lortie
6cd62920bb GActionGroup is now an interface
- make GAction.get_state() return a reference
 - fix some leaks/warnings in the tests
 - fix signal propagation in GSimpleActionGroup
2010-08-30 19:26:37 +02:00
Christian Persch
9493925854 Make g_emblemed_icon_add_emblem() keep the list sorted
Fixes bug #628317.
2010-08-30 18:34:14 +02:00
Christian Persch
7a6f8bd3c3 Don't leak the FD list
==6793== 32 (24 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 780 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 0x41DB582: g_unix_fd_list_new_from_array (gunixfdlist.c:191)
==6793==    by 0x421BFD6: _g_dbus_worker_do_read_cb (gdbusprivate.c:590)

Bug #628329.
2010-08-30 18:33:47 +02:00
Christian Persch
fa671dc5e2 Fix invalid reads
Don't use a guint16* when getting a guint property via g_object_get()!

Bug #628323.
2010-08-30 10:21:43 -04:00
Christian Persch
08924ad147 Plug a mem leak in GConverterOutputStream
==8221== 1,047 (672 direct, 375 indirect) bytes in 28 blocks are definitely lost in loss record 589 of 603
==8221==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==8221==    by 0x4057094: g_malloc (gmem.c:134)
==8221==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==8221==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==8221==    by 0x403A8A6: g_error_new_literal (gerror.c:117)
==8221==    by 0x403AC31: g_set_error_literal (gerror.c:314)
==8221==    by 0x80499DC: g_compressor_converter_convert (converter-stream.c:267)
==8221==    by 0x417BF67: g_converter_convert (gconverter.c:174)
==8221==    by 0x417D7F0: g_converter_output_stream_write (gconverteroutputstream.c:428)
==8221==    by 0x41B57DF: g_output_stream_write (goutputstream.c:216)
==8221==    by 0x804A367: test_compressor (converter-stream.c:456)

Bug #628309.
2010-08-30 10:18:30 -04:00
Christian Persch
802c25832c Plug a mem leak
==6793== 19 (8 direct, 11 indirect) bytes in 1 blocks are definitely lost in loss record 640 of 1,423
==6793==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793==    by 0x4057094: g_malloc (gmem.c:134)
==6793==    by 0x40573DB: g_malloc_n (gmem.c:281)
==6793==    by 0x4073D1B: g_strsplit (gstrfuncs.c:2436)
==6793==    by 0x4224A89: initable_init (gdbusserver.c:1040)
==6793==    by 0x41A73F9: g_initable_init (ginitable.c:105)
==6793==    by 0x41A759B: g_initable_new_valist (ginitable.c:218)
==6793==    by 0x41A743E: g_initable_new (ginitable.c:138)
==6793==    by 0x42238F5: g_dbus_server_new_sync (gdbusserver.c:484)

Bug #628328.
2010-08-30 10:16:31 -04:00
Christian Persch
6879256f36 Plug a mem leak
==6793== 16 bytes in 1 blocks are definitely lost in loss record 632 of 1,423
==6793==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793==    by 0x4057094: g_malloc (gmem.c:134)
==6793==    by 0x417FC29: g_data_input_stream_read_line (gdatainputstream.c:797)
==6793==    by 0x41F99C1: _my_g_data_input_stream_read_line (gdbusauth.c:279)
==6793==    by 0x41FA728: _g_dbus_auth_run_client (gdbusauth.c:759)

Bug #628327.
2010-08-30 10:14:39 -04:00
Matthias Clasen
bb221b68df Add an annotation 2010-08-30 10:02:32 -04:00
Dan Winship
a3cc274fc6 GSocketClient: fix a crash on cancellation
some code rearrangement when adding proxy support resulted in trying to
use a GSocket that wasn't there.

https://bugzilla.gnome.org/show_bug.cgi?id=628296
2010-08-30 09:31:47 -04:00
Matthias Clasen
b8ff287167 Disable the 'extra data' test for now 2010-08-30 08:58:31 -04:00
Matthias Clasen
b4a61235da Introspection: make 'direction' default to 'in' for methods 2010-08-30 08:50:09 -04:00
Matthias Clasen
c3135d1d39 Add some more gdbus introspection tests (currently failing) 2010-08-30 08:49:41 -04:00
Philip Withnall
1399913f31 Change "type-string" to "type string" in translatable strings
Helps: bgo#628193
2010-08-29 00:38:18 +01:00
Philip Withnall
ea9f5f0251 Change "lock-file" to "lock file" in translatable strings
Helps: bgo#628193
2010-08-29 00:38:06 +01:00
David Zeuthen
1e7243ad7b Bug 628084 – gdbus-peer fails with assertion
Make it work on systems where /etc/hosts is bigger than 1024 bytes.

https://bugzilla.gnome.org/show_bug.cgi?id=628084

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-27 10:50:03 -04:00
David Zeuthen
0d0a9bb448 GDBusConnection: Document memory management semantics for get_property()
Turns out we are leaking non-floating GVariant instances returned by
get_property() functions.

Also avoid imprecise language such as "newly-allocated GVariant" as
this doesn't specify whether the variant can be floating or not.

Also see https://bugzilla.gnome.org/show_bug.cgi?id=627974 as it is
very related to this change.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-25 14:49:05 -04:00
Tor Lillqvist
6c24062880 Include gproxyaddress.h explicitly 2010-08-23 14:31:20 +03:00
Matthias Clasen
8f40c0e45a Improve GDBus introspection test coverage 2010-08-23 00:38:19 -04:00
David Zeuthen
847e4dfe7d GDBusMethodInvocation: nuke constructor
... that is, make it private. This makes sense because users are never
expected to create such objects themselves - only the GDBus core will
need this.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-22 22:58:29 -04:00
David Zeuthen
3ff9894826 Bug 624546 – Modification of GDBusMessage in filter function
Allow modifying a GDBusMessage in a filter function and also add tests
for this. This breaks API but leaves ABI (almost) intact - at least
dconf's GSettings backend (the only big user I know of) will keep
working.

https://bugzilla.gnome.org/show_bug.cgi?id=624546

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-05 20:37:27 -04:00
Matthias Clasen
040bffed38 Fix build on !unix
There was one code block still referring to fd_list outside of
the ifdef G_OS_UNIX. Pointed out by Sam Thursfield in bug 627392.
2010-08-21 22:14:28 -04:00
Matthias Clasen
41ce91d057 Better fix for the build problem
Use gnetworkingprivate.h instead, patch by Emilio Pozuelo Monfort,
bug 627407.
2010-08-21 22:09:32 -04:00
Matthias Clasen
3d01283f69 Make gdbus-peer build on !linux
Based on a patch by Koop Mast, bug 627088.
2010-08-21 22:06:56 -04:00
Matthias Clasen
61de05e774 Fix a duplicate word
Pointed out in bug 627604.
2010-08-21 21:58:51 -04:00
Matthias Clasen
a54e2c4fb3 Add some more annotations 2010-08-21 19:27:11 -04:00
Matthias Clasen
892f9b6458 Improve test coverage for actions and action groups 2010-08-21 19:18:40 -04:00
Matthias Clasen
33b775308b Document behaviour wrt. to floating variants 2010-08-21 19:18:17 -04:00
Matthias Clasen
9581b33ca5 Document behaviour wrt to floating variants 2010-08-21 19:11:03 -04:00
Matthias Clasen
e8ffb1ae83 Add some annotations 2010-08-21 18:12:18 -04:00
Ryan Lortie
5b38bc5ad5 Simplify/fix state logic in GAction, test it. 2010-08-21 17:35:32 -04:00
Matthias Clasen
b876e47e3b Fix documentation issues
Gtk-doc is unhappy if the parameter names don't match between header
and source.
2010-08-21 15:34:40 -04:00
Matthias Clasen
4831a102e5 Fix GActionGroup docs 2010-08-21 15:34:18 -04:00
Dan Winship
8f5ec0dad3 Fix misc compiler warnings in (mostly) test programs 2010-08-19 18:24:53 -04:00
Dan Winship
22b3f0d4b2 gio.symbols: add missing g_simple_action_group stuff 2010-08-19 17:51:24 -04:00
Dan Winship
ab778737aa gproxyaddressenumerator.h: add missing G_END_DECLS 2010-08-19 17:51:01 -04:00
Nicolas Dufresne
de1598a34d gio/proxy: Fixed compilation warnings
* Wrong return type (NULL instead of FALSE)
* Unused static function declaration
2010-08-19 17:31:42 -04:00
Nicolas Dufresne
0958e66317 Add support for g_socket_client_add_application_proxy()
This allow application to take control over certain proxy protocol
handling. When a proxy protocol must be used and is found in the
application proxies, GSocketClient will simply TCP connect to the proxy
server and return the connection.

Reviewed-by: Dan Winship <danw@gnome.org>
2010-08-19 16:32:38 -04:00
Nicolas Dufresne
ced1d0e2e7 Implemented SOCKSv4 and SOCKSv4a 2010-08-19 16:32:38 -04:00
Nicolas Dufresne
e2a90bcb5f Implemented proxy sample code that connect to proxy 2010-08-19 16:32:38 -04:00
Nicolas Dufresne
0ebb79a748 Implemented g_socket_client_connect_to_uri() method
Using this rather than g_socket_client_connect() or
g_socket_client_connect_to_host() allows #GSocketClient to
determine when to use application-specific proxy protocols.

Reviewed-by: Dan Winship <danw@gnome.org>
2010-08-19 16:32:37 -04:00
Nicolas Dufresne
a6c3820f46 Hooked proxy enumeration into GSocketClient
This functionnallity can be disabled using property enable-proxy. It
enumerates addresses using GSocketConnectable::proxy_enumerate() instead of
enumerate(). When the returned address is of type GProxyAddress (a type
based on GInetSocketAddress), it gets the proxy protocol handler using
g_proxy_get_default_for_protocol() and call connect() on it.

Reviewed-by: Dan Winship <danw@gnome.org>
2010-08-19 16:32:37 -04:00
Nicolas Dufresne
ee3dbf747e Implement GProxyConnection a GIOStream+GTcpConn wrapper
This class inherit from GTcpConnection by refing the socket of
an existing GTcpConnection and wraps a custom GIOStream into itself. This
is to allow implementing proxies that alters data stream, like when using
GSSAPI privacy inside SOCKS5.
2010-08-19 16:32:37 -04:00
Nicolas Dufresne
6fa1136600 Implemented SOCKSv5 proxy support 2010-08-19 16:32:37 -04:00
Dan Winship
c32ef1d85e GSocket: store the remote_address when connecting
This way, if g_socket_connect() is called with a GProxyAddress,
g_socket_get_remote_address() will later return that same address.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk>
2010-08-19 16:32:37 -04:00
Nicolas Dufresne
b304a23af7 Extend IO_ERROR enum for Proxy support 2010-08-19 16:32:37 -04:00
Nicolas Dufresne
1094c84238 Implemented proxy sample for all Connectables 2010-08-19 16:32:37 -04:00
Nicolas Dufresne
fc03ecce83 Implemented proxy_enumerate() for all Connectables
This patch implements method proxy_enumerate from GSocketConnectable for
all connectables (GNetworkAddress, GNetworkService, GInetSocketAddress
and GUnixSocketAddress).

Reviewed-by: Dan Winship <danw@gnome.org>
2010-08-19 16:32:37 -04:00
Nicolas Dufresne
f82f484b8f Added proxy_enumerate method to GSocketConnectable
Reviewed-by: Dan Winship <danw@gnome.org>
2010-08-19 16:32:37 -04:00
Nicolas Dufresne
6749ffce59 Added GProxyAddressEnumerator to proxy sample code 2010-08-19 16:32:37 -04:00
Nicolas Dufresne
a7e0e8fc08 Adding GProxyAddressEnumerator class
An implementation of GSocketAddressEnumerator that handles proxy
enumeration. This class is mainly usefull for Connectables implementation
such as NetworkService, NetworkAddress and SocketAddress to handle proxies.

Reviewed-by: Dan Winship <danw@gnome.org>
2010-08-19 16:32:37 -04:00
Nicolas Dufresne
d76de5e359 Added GProxy interface for proxy extension point
Implement an extension point for proxy protocol implementation. This
is mainly useful for socket-based proxy where it is possible to use the
proxied socket the same way it would for other stream based socket.

Reviewed-by: Dan Winship <danw@gnome.org>
2010-08-19 16:32:37 -04:00
Nicolas Dufresne
63105d1074 Added method g_network_address_parse_uri()
This method allow creating a network address from a URI. If no port is
found in the URI, the default_port parameter will be used. Note that new
property scheme is there for future TLS implementation.

Reviewed-by: Dan Winship <danw@gnome.org>
2010-08-19 16:32:37 -04:00
Nicolas Dufresne
466111c960 Implement GProxyAddress
A GSocketInetAddress representing the proxy server address with additional
properties proxy type, destination address and port, username and password.

Reviewed-by: Dan Winship <danw@gnome.org>
2010-08-19 16:32:37 -04:00
Nicolas Dufresne
6b1d851cc5 Implemented proxy sample code
Reviewed-by: Dan Winship <danw@gnome.org>
2010-08-19 16:32:36 -04:00
Nicolas Dufresne
f3debedfd2 Implemented proxy-resolver extension point
This extension point allow extending GLib with library like LibProxy that
interprets system proxy settings and finds the appropriate configuration
based on the type of connection being made.

Reviewed-by: Dan Winship <danw@gnome.org>
2010-08-19 16:32:36 -04:00
David Zeuthen
7d6a6ca57b Bug 627188 – gdbus-non-socket test occasionally fails
Fix logical bug in test case to avoid race condition between the
client and the server.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-18 13:09:04 -04:00
Matthias Clasen
6c340c0b03 Make gunixcredentialsmessage.h standalone includable 2010-08-18 12:07:38 -04:00
Emmanuele Bassi
81b91a8852 action: Minor fixes
• Argument validation.

• Since: annotations.

• Remove (allow-none) annotations from return values.

• Coding style fixes.
2010-08-18 16:55:40 +01:00
Emmanuele Bassi
504117e284 action-group: Check aginst the correct GType macro
G_TYPE_ACTION_GROUP is not a G_TYPE_ACTION.
2010-08-18 16:55:40 +01:00
David Zeuthen
5bb94348f4 GDBusProxy: Call into well-known name if no name owner currently exists
This is really what (API) users expect from GDBusProxy - in
particular, mclasen and I ran into this problem while debugging a
upower issue, see

 https://bugzilla.redhat.com/show_bug.cgi?id=624125

In a nutshell, the problem is that polkitd crashes while upower holds
a PolkitAuthority object (which in turns contains a GDBusProxy for the
well-known name org.freedesktop.PolicyKit1). This means that
subsequent calls on the PolkitAuthority (which is translated into
calls into the GDBusProxy) fails since :g-name-owner is NULL.

With this fix, we'll be requesting the bus daemon to launch polkitd
since we will start calling into org.freedesktop.PolicyKit1 as soon as
we notice that there is no owner for this name.

Unfortunately our test suite doesn't cover service activation so there
is no way to reliably test this. I will file a bug about this.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-18 11:35:25 -04:00
David Zeuthen
c2945808ac GDBusProxy: Use %, not #, for referencing enum constants in gtk-doc comments
Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-18 10:52:28 -04:00
Ryan Lortie
5db9e5ad58 add GSimpleActionGroup
and a simple test
2010-08-18 02:18:54 -04:00