This bug was exposed by fixing the following leak in the resources test:
==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)
==29204== 7,192 (76 direct, 7,116 indirect) bytes in 1 blocks are definitely lost in loss record 855 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 0x424E815: g_zlib_decompressor_new (gzlibdecompressor.c:270)
==29204== by 0x4228DD8: g_resource_lookup_data (gresource.c:422)
==27020== 44 (24 direct, 20 indirect) bytes in 1 blocks are definitely lost in loss record 684 of 936
==27020== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27020== by 0x4084724: standard_malloc (gmem.c:85)
==27020== by 0x40847C7: g_malloc (gmem.c:159)
==27020== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==27020== by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==27020== by 0x40B5277: g_variant_get_variant (gvariant.c:749)
==27020== by 0x4273182: gvdb_table_value_from_item (gvdb-reader.c:478)
==27020== by 0x42731E8: gvdb_table_get_value (gvdb-reader.c:509)
==27020== by 0x4228B36: do_lookup (gresource.c:280)
==27020== by 0x4228F56: g_resource_get_info (gresource.c:492)
==26427== 24 bytes in 1 blocks are definitely lost in loss record 608 of 965
==26427== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==26427== by 0x4084724: standard_malloc (gmem.c:85)
==26427== by 0x40847C7: g_malloc (gmem.c:159)
==26427== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==26427== by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==26427== by 0x40BA89F: g_variant_valist_get (gvariant.c:4482)
==26427== by 0x40BAC23: g_variant_get_va (gvariant.c:4681)
==26427== by 0x40BAB29: g_variant_get (gvariant.c:4633)
==26427== by 0x4228BA5: do_lookup (gresource.c:293)
==26427== by 0x4228F51: g_resource_get_info (gresource.c:493)
We need to do this because constructors run before main() and
thus before any call to g_mem_set_vtable, making it impossible to
use that function if constructors call g_malloc.
We do this by making the constructors just register the static data
for lazy registration, doing the lazy registration when using
the global resource set.
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.
GResource is a bundle of files combined into a single binary blog.
The API lets you access the files the resource contains by
using resource paths. You can also register resources with a
global list and access these globally in a merged resource namespace.
The normal way this is used is to link in the resources into your
application/library and have it be automatically registred.
Resources are compiled from an xml description using
glib-compile-resources.
