Correct freeing of GError with dbus-glib

[Mike Crowe]

I have a simple dbus server that is implemented on top of
dbus-glib-0.82 using dbus-binding-tool. Under various error conditions
it returns custom errors via the GError * out parameter.

When running the server under valgrind-3.5.0 the strings associated
with each error appears to leak:

==13127== 21 bytes in 7 blocks are possibly lost in loss record 214 of 456
==13127==    at 0x4C9D8EC: malloc (vg_replace_malloc.c:195)
==13127==    by 0x72D1769: vasprintf (in /emul/ia32-linux/lib/libc-2.7.so)
==13127==    by 0x6EE7D26: g_vasprintf (gprintf.c:313)
==13127==    by 0x6ED41F5: g_strdup_vprintf (gstrfuncs.c:218)
==13127==    by 0x6EA1611: g_set_error (gerror.c:45)
==13127==    by 0x804CCE5: SetGErrorInvalidName(_GError**, Registry::InvalidName const&) (registry_server.cpp:87)
==13127==    by 0x804DC5F: registry_section_exists (registry_server.cpp:205)
==13127==    by 0x804EB04: dbus_glib_marshal_registryd_BOOLEAN__STRING_POINTER_POINTER (registry-server-glue.h:247)
==13127==    by 0x4CB3C17: object_registration_message (dbus-gobject.c:1446)
==13127==    by 0x6E60264: _dbus_object_tree_dispatch_and_unlock (dbus-object-tree.c:856)
==13127==    by 0x6E51653: dbus_connection_dispatch (dbus-connection.c:4487)
==13127==    by 0x4CAF59C: message_queue_dispatch (dbus-gmain.c:101)
==13127==    by 0x6EB1807: g_main_context_dispatch (gmain.c:2012)
==13127==    by 0x6EB4E52: g_main_context_iterate (gmain.c:2645)
==13127==    by 0x6EB5351: g_main_loop_run (gmain.c:2853)
==13127==    by 0x8050F53: main (registryd.cpp:308)

Looking through dbus-gobject.c I can see how the error is turned into
something that can be sent back across the bus but at no point can I
see the original error being freed.

If I add a call to g_clear_error(&gerror) somewhere near the end of
invoke_object_method then I no longer see this memory leak. However,
I'm not convinced that I've uncovered the whole story. Is something
else supposed to be freeing the error?

I've done a bit of searching through the archives and couldn't find
anything appropriate.

Thanks.

Mike.