Emmanuele Bassi [Wed, 18 Aug 2010 14:32:27 +0000 (15:32 +0100)]
gobject: Add install_properties()
Since we added g_object_notify_by_pspec(), an efficient way to install
and notify properties relies on storing the GParamSpec pointers inside
a static arrays, like we do for signal identifiers.
Instead of multiple calls to g_object_class_install_property(), we
should have a single function to take the static array of GParamSpecs
and iterate it.
https://bugzilla.gnome.org/show_bug.cgi?id=626919
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
Daniel Nylander [Sun, 12 Sep 2010 18:25:57 +0000 (20:25 +0200)]
Updated Swedish translation
Ryan Lortie [Sun, 12 Sep 2010 17:35:30 +0000 (13:35 -0400)]
GSettings: no writability->value change assumption
GSettings internally assumed that a change in key writability implied a
change in value. That may be true for some backends. Let those
backends deal with the situation for themselves.
Tor Lillqvist [Sun, 12 Sep 2010 10:58:13 +0000 (13:58 +0300)]
Add some more individual own header includes where required
Mario Blättermann [Sun, 12 Sep 2010 09:02:47 +0000 (11:02 +0200)]
[i18n] Updated German translation
Takayuki KUSANO [Sat, 11 Sep 2010 18:02:24 +0000 (03:02 +0900)]
Updatede Japanese translation.
Tomeu Vizoso [Sat, 11 Sep 2010 15:01:10 +0000 (17:01 +0200)]
Add annotation for g_variant_get_string
Andika Triwidada [Sat, 11 Sep 2010 09:29:06 +0000 (16:29 +0700)]
Updated Indonesian translation
Tor Lillqvist [Sat, 11 Sep 2010 09:08:32 +0000 (12:08 +0300)]
dos2unix glib/win_iconv.c
Benjamin Otte [Fri, 10 Sep 2010 22:12:13 +0000 (00:12 +0200)]
docs: Clarify string encoding for GFile constructors
The encoding was deduced from looking at the source code, feel free to
fix if it's wrong (the docs _and_ the source code).
David Zeuthen [Fri, 10 Sep 2010 20:21:37 +0000 (16:21 -0400)]
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>
David Zeuthen [Fri, 10 Sep 2010 17:27:48 +0000 (13:27 -0400)]
Remove g_dbus_message_filter_result_get_type() from gio.symbols
Pointed out by danw on IRC.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Dan Winship [Fri, 10 Sep 2010 13:12:17 +0000 (09:12 -0400)]
g_socket_client_connect_async: fix when g_socket_connect succeeds immediately
https://bugzilla.gnome.org/show_bug.cgi?id=629251
Dan Winship [Fri, 10 Sep 2010 12:51:21 +0000 (08:51 -0400)]
Fix IPv6 parsing in _g_uri_parse_authority, add _g_uri_from_authority
Fixes connections to IPv6 address literals.
https://bugzilla.gnome.org/show_bug.cgi?id=629259
Ryan Lortie [Thu, 9 Sep 2010 20:28:18 +0000 (16:28 -0400)]
Add 3 new restrictions to the schema compiler
- can not extend schemas that already have paths
- can not form list of schemas that already have paths
- the path of a list schema, if given, must end with ':/'
Ryan Lortie [Thu, 9 Sep 2010 20:12:45 +0000 (16:12 -0400)]
Rename gschema-compile.c -> glib-compile-schemas.c
Ryan Lortie [Mon, 6 Sep 2010 16:47:37 +0000 (12:47 -0400)]
split GSettings.list_items => list_{children,keys}
This is an incompatible public API/ABI change.
Ryan Lortie [Thu, 9 Sep 2010 19:45:53 +0000 (15:45 -0400)]
Create GSettingsListenerVTable
...instead of passing a whole whack of function pointers around
This is an internal API.
David Zeuthen [Thu, 9 Sep 2010 19:15:13 +0000 (15:15 -0400)]
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>
David Zeuthen [Thu, 9 Sep 2010 18:14:45 +0000 (14:14 -0400)]
GUnixConnection: Remove comment about Linux
Since the previous commit, the g_unix_connection_send_credentials() /
g_unix_connection_receive_credentials() functions now also works on
FreeBSD since GUnixCredentialsMessage now works there.
The main idea is that the g_unix_connection_send_credentials() /
g_unix_connection_receive_credentials() functions are the "main" API
for getting credentials (one way or the other). So it's better to
avoid advertising where it is currently implemented.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Joe Marcus Clarke [Thu, 9 Sep 2010 18:10:01 +0000 (14:10 -0400)]
Bug 628904 – Add credential support for FreeBSD and fix a socket issue
Signed-off-by: David Zeuthen <davidz@redhat.com>
David Zeuthen [Thu, 9 Sep 2010 18:00:46 +0000 (14:00 -0400)]
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>
David Zeuthen [Thu, 9 Sep 2010 17:21:35 +0000 (13:21 -0400)]
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>
David Zeuthen [Thu, 9 Sep 2010 16:00:00 +0000 (12:00 -0400)]
Fix tmpl files
Signed-off-by: David Zeuthen <davidz@redhat.com>
David Zeuthen [Thu, 9 Sep 2010 15:37:14 +0000 (11:37 -0400)]
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>
Emmanuele Bassi [Wed, 8 Sep 2010 08:58:42 +0000 (11:58 +0300)]
Revert hack that broke things badly on Windows
This should fix bug #628952.
Don't include glib/gdatasetprivate.h directly. Especially don't define
GLIB_COMPILATION when doing that, as that causes breakage on Windows
because of the variable dllimport/dllexport stuff in gtypes.h that
checks GLIB_COMPILATION. That macro really should be defined only when
compiling code that goes into the libglib DLL. Otherwise the compiler
thinks that variables that should be imported from libglib are
actually defined in the code being compiled.
Just call g_atomic_pointer_get() as such, don't bother with
G_DATALIST_GET_FLAGS.
Signed-off-by: Tor Lillqvist <tml@iki.fi>
Inaki Larranaga Murgoitio [Tue, 7 Sep 2010 16:03:19 +0000 (18:03 +0200)]
Updated Basque language
Piotr Drąg [Tue, 7 Sep 2010 15:43:37 +0000 (17:43 +0200)]
Updated Polish translation
Piotr Drąg [Tue, 7 Sep 2010 15:42:19 +0000 (17:42 +0200)]
Updated Polish translation
Duarte Loreto [Mon, 6 Sep 2010 23:33:02 +0000 (00:33 +0100)]
Updated Portuguese translation
Duarte Loreto [Mon, 6 Sep 2010 23:29:36 +0000 (00:29 +0100)]
Updated Portuguese translation
Daniel Nylander [Mon, 6 Sep 2010 21:10:09 +0000 (23:10 +0200)]
Updated Swedish translation
Gabor Kelemen [Mon, 6 Sep 2010 13:07:02 +0000 (15:07 +0200)]
Updated Hungarian translation
Tor Lillqvist [Mon, 6 Sep 2010 12:56:16 +0000 (15:56 +0300)]
Fix build on Windows and possibly other non-Linux platforms
Include glibconfig.h in files that test G_OS_WIN32. Include headers
for GLib APIs used conditionally where needed.
Emmanuele Bassi [Mon, 6 Sep 2010 11:26:40 +0000 (12:26 +0100)]
Whitespace fixes
Damien Lespiau [Sun, 5 Sep 2010 20:47:44 +0000 (21:47 +0100)]
datetime: Rename shadowing variables
timezone and tzname shadow variables declared in time.h. Let's rename
them to time_zone and tz_name then.
https://bugzilla.gnome.org/show_bug.cgi?id=628839
Thiago Santos [Fri, 3 Sep 2010 13:43:11 +0000 (14:43 +0100)]
gdatetime: Use proleptic gregorian
Use Proleptic Gregorian calendar instead of the Julian calendar
as the internal representation.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
Christian Hergert [Tue, 31 Aug 2010 16:27:58 +0000 (09:27 -0700)]
datetime: use g_utf8_next_char() to walk utf8 string
Previously, the format string was iterated many times by
walking to the given offset in the string repeatedly.
This patch instead walks the string using g_utf8_next_char().
Additionally, the character for lookups was a char and could
loose content. This uses gunichar instead.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Christian Hergert [Tue, 31 Aug 2010 16:10:16 +0000 (09:10 -0700)]
datetime: avoid using __year
These were left over from when the inline functions where implemented
as macros. They are no longer needed and where clashing with the
global __year anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Emmanuele Bassi [Thu, 26 Aug 2010 14:23:13 +0000 (15:23 +0100)]
datetime: Add get_week_of_year()
https://bugzilla.gnome.org/show_bug.cgi?id=628029
Based on a patch by: Joseph Pingenot
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
Emmanuele Bassi [Thu, 26 Aug 2010 12:11:46 +0000 (13:11 +0100)]
datetime: Rename internal method
Use add_ymd(), to reflect the order of the arguments.
Emmanuele Bassi [Mon, 6 Sep 2010 10:43:04 +0000 (11:43 +0100)]
build: Fix warnings caused by missing includes
Khaled Hosny [Sun, 5 Sep 2010 14:23:00 +0000 (16:23 +0200)]
Updated Arabic translation
Chao-Hsiung Liao [Sun, 5 Sep 2010 11:24:01 +0000 (19:24 +0800)]
Updated Traditional Chinese translation(Hong Kong and Taiwan)
Matthias Clasen [Sun, 5 Sep 2010 04:23:03 +0000 (00:23 -0400)]
More header inclusion cleanup
Emmanuele Bassi [Sat, 4 Sep 2010 17:24:50 +0000 (18:24 +0100)]
build: Quench the compiler's thirst for warnings
Emmanuele Bassi [Sat, 4 Sep 2010 17:15:15 +0000 (18:15 +0100)]
gmain: Define _GNU_SOURCE before including glibconfig.h
As it pulls in unistd.h from something else.
Emmanuele Bassi [Sat, 4 Sep 2010 17:04:34 +0000 (18:04 +0100)]
Build fixes for the fall-out of the inclusion changes
Emmanuele Bassi [Sat, 4 Sep 2010 17:03:33 +0000 (18:03 +0100)]
gtimer: Fix a compilation warning
Emmanuele Bassi [Sat, 4 Sep 2010 16:22:39 +0000 (17:22 +0100)]
Hack to include glib/gdatasetprivate.h directly
The gdatasetprivate.h header includes gatomic.h directly. It all works
well in GLib, but inside GObject it will trigger the single inclusion
guard.
Since this is a private header, and it's kind of a special case, one way
to fix it is to declare GLIB_COMPILATION around it and fool the single
inclusion guard in gatomic.h into thinking we're compiling GLib and not
GObject.
Emmanuele Bassi [Sat, 4 Sep 2010 16:22:18 +0000 (17:22 +0100)]
Add missing gstrfuncs.h include
For g_strdup() and friends.
Matthias Clasen [Sat, 4 Sep 2010 03:03:14 +0000 (23:03 -0400)]
More include cleanups
Matthias Clasen [Sat, 4 Sep 2010 01:24:40 +0000 (21:24 -0400)]
Don't include glib.h in other headers
Matthias Clasen [Sat, 4 Sep 2010 01:20:07 +0000 (21:20 -0400)]
Remove excessive header includes
Matthias Clasen [Sat, 4 Sep 2010 01:15:45 +0000 (21:15 -0400)]
Remove excessive header includes
Matthias Clasen [Sat, 4 Sep 2010 01:12:03 +0000 (21:12 -0400)]
Don't include glib.h in other headers
Matthias Clasen [Sat, 4 Sep 2010 00:57:05 +0000 (20:57 -0400)]
Remove excessive header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:55:17 +0000 (20:55 -0400)]
Remove excessive header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:53:37 +0000 (20:53 -0400)]
Remove excessive header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:51:08 +0000 (20:51 -0400)]
Remove excessive header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:46:40 +0000 (20:46 -0400)]
Remove some unneeded headers
Matthias Clasen [Sat, 4 Sep 2010 00:44:59 +0000 (20:44 -0400)]
Remove eexcessive header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:41:52 +0000 (20:41 -0400)]
Remove redundant header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:38:30 +0000 (20:38 -0400)]
Remove redundant header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:34:15 +0000 (20:34 -0400)]
Remove redundant header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:30:54 +0000 (20:30 -0400)]
Remove redundant header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:27:45 +0000 (20:27 -0400)]
Remove redundant header inclusions
and some whitespace cleanup.
Matthias Clasen [Sat, 4 Sep 2010 00:15:16 +0000 (20:15 -0400)]
Remove redundant header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:12:09 +0000 (20:12 -0400)]
Remove redundant header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:05:27 +0000 (20:05 -0400)]
Remove redundant header inclusions
Matthias Clasen [Sat, 4 Sep 2010 00:01:55 +0000 (20:01 -0400)]
Remove redundant header inclusions
Matthias Clasen [Fri, 3 Sep 2010 23:49:34 +0000 (19:49 -0400)]
Remove redundant header inclusions
and clean up some whitespace
Matthias Clasen [Fri, 3 Sep 2010 23:41:49 +0000 (19:41 -0400)]
Remove redundant header inclusions
and clean up some whitespace
Matthias Clasen [Fri, 3 Sep 2010 23:38:56 +0000 (19:38 -0400)]
Whitespace cleanup
Matthias Clasen [Fri, 3 Sep 2010 23:37:54 +0000 (19:37 -0400)]
Remove redundant header inclusions
Matthias Clasen [Fri, 3 Sep 2010 23:33:11 +0000 (19:33 -0400)]
Whitespace cleanup
Matthias Clasen [Fri, 3 Sep 2010 23:32:02 +0000 (19:32 -0400)]
Remove redundant header inclusions
Matthias Clasen [Fri, 3 Sep 2010 23:03:34 +0000 (19:03 -0400)]
Sort extensions properly
Just taking the difference of the priorities has overflow issues,
as pointed out in bug 623069.
Matthias Clasen [Fri, 3 Sep 2010 22:11:08 +0000 (18:11 -0400)]
Add a note about size limits of private structures
Also add some assertions to check these limits, instead of
failing silently. Bug 604479.
Christian Persch [Fri, 3 Sep 2010 20:05:28 +0000 (16:05 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 20:04:29 +0000 (16:04 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 20:03:48 +0000 (16:03 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 20:02:11 +0000 (16:02 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 20:01:10 +0000 (16:01 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 20:00:15 +0000 (16:00 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:58:51 +0000 (15:58 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:57:26 +0000 (15:57 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:56:23 +0000 (15:56 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:55:10 +0000 (15:55 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:53:56 +0000 (15:53 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:53:05 +0000 (15:53 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:47:38 +0000 (15:47 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:45:48 +0000 (15:45 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:44:28 +0000 (15:44 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:43:03 +0000 (15:43 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:40:55 +0000 (15:40 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:39:58 +0000 (15:39 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:39:07 +0000 (15:39 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:37:56 +0000 (15:37 -0400)]
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.
Christian Persch [Fri, 3 Sep 2010 19:37:08 +0000 (15:37 -0400)]
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.