Don't call LoadLibrary() on shell32.dll or kernel32.dll. kernel32.dll
is always loaded. Shell32.dll is also already loaded as glib links to
functions in it. So just call GetModuleHandle() on them.
For mlang.dll in win_iconv.c and winhttp.dll in gwinhttpvfs.c, always
try loading them from a complete path, from the Windows system
directory.
Use the "tool help" API to enumerate modules in gmodule-win32.c. It is
present in all Windows versions since Windows 2000, which is all we
support anyway. Thus no need to look that API up dynamically. Just
link to it normally. We can bin the fallback code that attempts to use
the psapi API.
Looks like we forgot to ref the returned GVariant in
g_dbus_proxy_call_finish().
It's a good question why code using g_dbus_proxy_call() and
g_dbus_proxy_call_finish() worked in the first place - probably the
answer is that no-one really used these APIs.
Signed-off-by: David Zeuthen <davidz@redhat.com>
==6793== 32 (24 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 780 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 0x41DB582: g_unix_fd_list_new_from_array (gunixfdlist.c:191)
==6793== by 0x421BFD6: _g_dbus_worker_do_read_cb (gdbusprivate.c:590)
Bug #628329.
==8221== 1,047 (672 direct, 375 indirect) bytes in 28 blocks are definitely lost in loss record 589 of 603
==8221== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==8221== by 0x4057094: g_malloc (gmem.c:134)
==8221== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==8221== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==8221== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==8221== by 0x403AC31: g_set_error_literal (gerror.c:314)
==8221== by 0x80499DC: g_compressor_converter_convert (converter-stream.c:267)
==8221== by 0x417BF67: g_converter_convert (gconverter.c:174)
==8221== by 0x417D7F0: g_converter_output_stream_write (gconverteroutputstream.c:428)
==8221== by 0x41B57DF: g_output_stream_write (goutputstream.c:216)
==8221== by 0x804A367: test_compressor (converter-stream.c:456)
Bug #628309.
==6793== 19 (8 direct, 11 indirect) bytes in 1 blocks are definitely lost in loss record 640 of 1,423
==6793== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793== by 0x4057094: g_malloc (gmem.c:134)
==6793== by 0x40573DB: g_malloc_n (gmem.c:281)
==6793== by 0x4073D1B: g_strsplit (gstrfuncs.c:2436)
==6793== by 0x4224A89: initable_init (gdbusserver.c:1040)
==6793== by 0x41A73F9: g_initable_init (ginitable.c:105)
==6793== by 0x41A759B: g_initable_new_valist (ginitable.c:218)
==6793== by 0x41A743E: g_initable_new (ginitable.c:138)
==6793== by 0x42238F5: g_dbus_server_new_sync (gdbusserver.c:484)
Bug #628328.
==6793== 16 bytes in 1 blocks are definitely lost in loss record 632 of 1,423
==6793== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793== by 0x4057094: g_malloc (gmem.c:134)
==6793== by 0x417FC29: g_data_input_stream_read_line (gdatainputstream.c:797)
==6793== by 0x41F99C1: _my_g_data_input_stream_read_line (gdbusauth.c:279)
==6793== by 0x41FA728: _g_dbus_auth_run_client (gdbusauth.c:759)
Bug #628327.
