These were the last users of the dynamic allocation API.
Keep the uses in glib/tests/mutex.c since this is actually meant to test
the API (which has to continue working, even if it is deprecated).
https://bugzilla.gnome.org/show_bug.cgi?id=660739
==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.
==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.
GFile allows for the possibility that external implementations may not
support thread-default contexts yet, via
g_file_supports_thread_contexts(). GVolumeMonitor is not yet
thread-default-context aware.
Add a test program to verify that basic gio async ops work correctly
in non-default contexts.
http://bugzilla.gnome.org/show_bug.cgi?id=579984
