When presented with an array of empty arrays of 8-byte-aligned types,
GDBus would incorrectly apply the 8-byte alignment when reading back.
https://bugzilla.gnome.org/show_bug.cgi?id=673612
Signed-off-by: David Zeuthen <davidz@redhat.com>
GDBus heavily relies on idles for some of its cleanup operations,
and not running a mainloop leads to things not getting cleaned
up properly, which in turn leads to test failures, since the
session bus singleton does not get removed.
This program is only used indirectly from gapplication.c in
tests, but that is no reason to let it segfault when it is
run from the commandline without arguments.
GDBusProxy sets an error on a GSimpleAsyncResult and then returns
without dispatching the result for completion (and leaks the result in
the process). Fix that.
Also add a testcase. Unfortunately, adding the testcase uncovered
bug #672248. We can work around that by reordering the tests.
https://bugzilla.gnome.org/show_bug.cgi?id=672249
g_file_read() was returning G_IO_ERROR_IS_DIRECTORY when you tried to
open a directory on unix, but G_IO_ERROR_PERMISSION_DENIED on win32.
Fix that, and add a test to tests/file.c
Pointed out on IRC by Paweł Forysiuk.
https://bugzilla.gnome.org/show_bug.cgi?id=669330
This is useful when using certain D-Bus services where the
PropertiesChanged signal does not include the property value such as
e.g. various systemd mechanisms, see e.g.
https://bugs.freedesktop.org/show_bug.cgi?id=37632
Signed-off-by: David Zeuthen <davidz@redhat.com>
==1265== 84 (8 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 793 of 827
==1265== at 0x4029467: calloc (vg_replace_malloc.c:467)
==1265== by 0x408479B: standard_calloc (gmem.c:104)
==1265== by 0x4084846: g_malloc0 (gmem.c:189)
==1265== by 0x4084B2D: g_malloc0_n (gmem.c:385)
==1265== by 0x4228A98: g_resource_load (gresource.c:253)
==1265== by 0x804A56D: test_resource_registred (resources.c:198)
==509== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 828 of 837
==509== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==509== by 0x4084724: standard_malloc (gmem.c:85)
==509== by 0x40847C7: g_malloc (gmem.c:159)
==509== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==509== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==509== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==509== by 0x804A48C: test_resource_data (resources.c:174)
==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204== by 0x4084724: standard_malloc (gmem.c:85)
==29204== by 0x40847C7: g_malloc (gmem.c:159)
==29204== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204== by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204== by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204== by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204== by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204== by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204== by 0x417C1DB: g_object_new (gobject.c:1535)
==29204== by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204== by 0x4228D38: g_resource_open_stream (gresource.c:363)
==28778== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 842 of 863
==28778== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28778== by 0x4084724: standard_malloc (gmem.c:85)
==28778== by 0x40847C7: g_malloc (gmem.c:159)
==28778== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==28778== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==28778== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==28778== by 0x804C2B1: test_uri_query_info (resources.c:435)
==28318== 38 (12 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 613 of 865
==28318== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28318== by 0x4084724: standard_malloc (gmem.c:85)
==28318== by 0x40847C7: g_malloc (gmem.c:159)
==28318== by 0x4084AB4: g_malloc_n (gmem.c:361)
==28318== by 0x4229599: g_resources_enumerate_children (gresource.c:806)
==28318== by 0x804B39E: test_resource_registred (resources.c:283)
==27820== 31 bytes in 1 blocks are definitely lost in loss record 587 of 866
==27820== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27820== by 0x4084724: standard_malloc (gmem.c:85)
==27820== by 0x40847C7: g_malloc (gmem.c:159)
==27820== by 0x4084AB4: g_malloc_n (gmem.c:361)
==27820== by 0x409D6A1: g_strdup (gstrfuncs.c:356)
==27820== by 0x4069FF7: g_get_current_dir (gfileutils.c:2544)
==27820== by 0x804BCA7: test_resource_module (resources.c:370)
The glib-compile-resources --generate-dependencies call was failing,
although not stopping the build.
Failed to open file 'test2.gresource.xml': No such file or directory
Failed to open file 'test3.gresource.xml': No such file or directory
Failed to open file 'test4.gresource.xml': No such file or directory
Failed to open file 'test.gresource.xml': No such file or directory
With this we're not longer exporting the constructor headers, which means
we're not tying ourselves to a macro that might need special tweaking on
a compiler-by-compiler basis.
It's hardly useful to bloat the resource data with blanks intended only
for human readability, so add a preprocessing option that uses xmllint --noblanks
to strip these.
Bug #667929.
struct sin6_addr has two additional fields that struct sin_addr
doesn't. Add support for those to GInetSocketAddress, and make sure
they don't get lost when converting between glib and native types.
https://bugzilla.gnome.org/show_bug.cgi?id=635554
