Commit Graph

363 Commits

Author SHA1 Message Date
Ryan Lortie
1612a4d506 volume monitor: don't unref NULL
Fix a couple more cases of blindly calling g_object_unref() on the
result of a function that is documented as sometimes returning NULL.
2010-10-05 02:29:47 -04:00
Ryan Lortie
3c5b50c424 GSettings test: fix error match strings
The name of the internal function that appears in an assertion message
has changed.  Update the tests.
2010-10-04 21:07:50 -04:00
Ryan Lortie
d6d76783ae Bug 631263 - GSettings needs range/choice APIs
Add g_settings_get_range() to describe the possible values that may be
provided to g_settings_set_value() without causing an error.

Add a test case.
2010-10-04 02:58:46 -04:00
Ryan Lortie
90822327ac GSettings test: fix unsafe GObject properties use
The test case was passing a guint16 to g_object_get() for a guint
property.  That's invalid on all systems, although it works (more or
less) on little endian ones.  On big endian it's a total no-go.
2010-10-03 22:55:53 -04:00
Ryan Lortie
d2c0699440 Clean up g_settings_list_schemas()
In its previous form, g_settings_list_schemas() was not useful as a tool
to prevent aborts due to using g_settings_new() with an invalid schema
name.  This is because g_settings_list_scheams() also listed relocatable
schemas, and calling g_settings_new() for those would abort just the
same as if you called it for a non-existent schema.

Modify g_settings_list_schemas() so that it only returns schemas for
which it is safe to call g_settings_new().  Add another call for sake of
completeness: g_settings_list_relocatable_schemas().
2010-10-02 22:42:02 -04:00
Ryan Lortie
ba0e608478 Improve .gitignore 2010-10-01 11:21:17 -04:00
Ryan Lortie
e40f3932dd Bug 628937 - gracefully handle broken schemas
Implement the first of two features requested in the bug: when
encountering a broken .xml schema file, back out the changes in that
file and continue to parse other files.

This prevents a single broken .xml file from messing up GSettings for
everyone else.

Add a --strict option to get the old behaviour.  Use this from the test
cases.
2010-10-01 11:21:02 -04:00
David Zeuthen
4d9ae95ae0 GDBus: Don't use abstract sockets in test code
It doesn't really work right now because of a dbus-daemon(1) bug - see
the comment added in the TODO section of gdbusconnection.c. So revert
to old behavior. The downside is a lot of files in /tmp but right now
that's better than not being able to run tests in a loop.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-23 19:16:25 -04:00
David Zeuthen
a35eb70471 GDBus: Use abstract namespace in test cases to avoid littering all over /tmp
Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-23 18:57:35 -04:00
David Zeuthen
7036415cc1 GDBusConnection: Use correct GMainContext when invoking free functions
Without this fix, the ./gdbus-connection test case occasionally fails, see

 https://bugzilla.gnome.org/show_bug.cgi?id=629945#c5

like this

 /gdbus/connection/basic: OK
 /gdbus/connection/life-cycle: **
ERROR:gdbus-connection.c:223:test_connection_life_cycle: assertion failed:
(!quit_mainloop_fired)
 cleaning up bus with pid 21794
 Aborted (core dumped)

because the callback didn't happen on the same thread as where we are
running the loop.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-23 17:36:07 -04:00
David Zeuthen
643e5526c5 GDBus: fix name test cases
Since we make message buses come and go, we need to ensure that the
singleton connection instance goes away before attempting to call
g_bus_get_sync() or similar.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-23 16:28:59 -04:00
David Zeuthen
71b1d738e2 GDBus: bump timeout for some tests
When under load, a one second timeout is just not enough. This can be
observed by e.g. restarting a CPU- and IO-intensive application like a
web browser with many tabs while running the test cases. Therefore,
bump the timeouts to 30 seconds.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-23 16:14:42 -04:00
David Zeuthen
1f6a9f1e2d GDBus: Move "slow" connection test cases into separate test program
Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-23 15:49:04 -04:00
David Zeuthen
f0b04acfd3 GDBusConnection: Avoid callbacks on finalized connection
Turns out that GDBusWorker will issue callbacks (in its own thread)
even after g_dbus_worker_stop() has been called. This would rarely
happen (and unreffing a connection is even rarer) so only saw this bug
occasionally when running the gdbus-connection test case in a loop.

Fix up this issue by maintaining a set of GDBusConnection objects that
are currently "alive" and do nothing in the callbacks if the passed
user_data pointer is not in this set.

Also attempted to fix up a race condition with
_g_object_wait_for_single_ref_do() and its use of GObject toggle
references - for now, just resort to busy waiting, thereby
sidestepping the toggle reference mess altogether.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-23 15:16:56 -04:00
Ryan Lortie
b4ee303ed6 .gitignore some test cases 2010-09-17 13:26:50 -04:00
Ryan Lortie
2e78d07f86 Add g_data_input_stream_read_upto{,async,finish}
These functions are meant to replace the read_until() flavour, with the
following improvements:

  - consistency between the synchronous and asynchronous versions as to
    if the separator character is read (it never is).

  - support for using a nul byte as a separator character by way of
    addition of a length parameter which allows stop_chars to be treated
    as a byte array rather than a nul-terminated string.

The read_until() functions are not yet formally deprecated, but a note
has been added to the documentation warning not to use them as they will
be in the future.

This is bug #584284.
2010-09-13 13:14:25 -04:00
David Zeuthen
0b74058fa3 Add work-around for Bug 627724
The root problem is with GObject - for now, just work around it in
GDBus. Also include a test-case. See

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

for more information.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-10 16:23:14 -04:00
Ryan Lortie
77e3badcf3 split GSettings.list_items => list_{children,keys}
This is an incompatible public API/ABI change.
2010-09-09 16:42:55 -04:00
David Zeuthen
7c66068544 GDBusMessage: Don't reset serial number when copying
Ryan pointed out that it's safe to do this because we have the
G_DBUS_SEND_MESSAGE_FLAGS_PRESERVE_SERIAL flag and that it simplifies
how filter functions work.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-09 15:15:13 -04:00
David Zeuthen
ee945d8f62 GDBusServer: Make ::new-connection return whether the connection was claimed
Otherwise things probably won't work in a garbage-collected world
(consider the trivial GC that never collects garbage).

This commit breaks GDBusServer ABI. No known released software is
using this code.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-09 14:02:31 -04:00
David Zeuthen
c3371efcaa Bug 624546 – Modification of GDBusMessage in filter function
Rework filter functions as per

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

This commit breaks ABI. However, this ABI break affects only
applications using filter functions. The only known user of is dconf.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-09 13:21:35 -04:00
David Zeuthen
67a00658ea GDBusMessage: Make it possible to lock and copy messages
Don't actually use this yet as that will require a couple of
modifications to the filter function signature. This is part of the
bug-fix for

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

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-09 12:00:32 -04:00
Emmanuele Bassi
19972a1b57 build: Quench the compiler's thirst for warnings 2010-09-04 18:24:50 +01:00
Christian Persch
db4fb1b115 Plug a mem leak in the gdbus-proxy test
==23341== 65 bytes in 3 blocks are definitely lost in loss record 927 of 1,020
==23341==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23341==    by 0x4057094: g_malloc (gmem.c:134)
==23341==    by 0x40573DB: g_malloc_n (gmem.c:281)
==23341==    by 0x40717FC: g_strdup (gstrfuncs.c:101)
==23341==    by 0x4147F56: value_lcopy_string (gvaluetypes.c:313)
==23341==    by 0x4123F0B: g_object_get_valist (gobject.c:1643)
==23341==    by 0x41240FF: g_object_get (gobject.c:1731)
==23341==    by 0x804C39E: test_basic (gdbus-proxy.c:522)

Bug #628331.
2010-09-03 16:05:28 -04:00
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