Commit Graph

8768 Commits

Author SHA1 Message Date
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
Matthias Clasen
c75429d0a0 Make ordering for overridden interface properties consistent
g_object_class_list_properties tries to sort the returned list of
paramspecs by 'type depth' and param_id. But all the overridden
interface properties have a param_id of 0, so they come out in
a random order.

Bug 628253.
2010-09-03 14:54:22 -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
Kjartan Maraas
54c51c73c6 Updated Norwegian bokmål translation 2010-09-02 11:56:09 +02:00
noch
b4d3acf9be Modified Armenian translation - po file 2010-09-02 12:35:41 +05: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
Jon Nordby
fb15dde6c1 docs: Inline docs from tmpl/memory.smgl 2010-09-01 09:48:16 +02:00
Andika Triwidada
4497e84215 Updated Indonesian translation 2010-09-01 09:54:52 +07:00
noch
94e34d8a12 Modified hy.po 2010-08-31 16:49:31 +05:00
noch
b10d3a73bc Modified hy.po 2010-08-31 12:36:12 +05:00
Matthias Clasen
e57884041b Bump version 2010-08-30 20:47:40 -04:00
Matthias Clasen
31a72dd719 Update symbol list 2010-08-30 19:31:45 -04:00
Branko Kokanović
ee2c6f4554 Updated Serbian translation 2010-08-31 02:33:26 +02:00
Philip Withnall
1d2229129c Update British English translation 2010-08-30 22:13:18 +01:00
Matthias Clasen
6f327315dc Add one more bug ref 2010-08-30 16:08:25 -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
Matthias Clasen
72ea8b1df7 Tweak the wording 2010-08-30 13:28:06 -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
Matthias Clasen
75891001bc Update NEWS for 2.25.15 2010-08-30 13:11:52 -04: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
Branko Kokanović
1ce14a88d6 Updated Serbian translation 2010-08-29 19:07:46 +02:00
Yaron Shahrabani
0e93b0f5c0 Updated Hebrew translation. 2010-08-29 15:57:41 +03:00
Jorge González
b09a01c626 Updated Spanish translation 2010-08-29 11:33:56 +02:00
A S Alam
2286d1d669 update translation for Punjabi 2010-08-29 09:32:03 +05:30