Commit Graph

1657 Commits

Author SHA1 Message Date
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