GNOME Bugzilla – Bug 618919
Registry/Plugin Loading Memory Leak
Last modified: 2010-10-25 12:52:30 UTC
Created attachment 161255 [details] Valgrind Log Valgrind, with no suppressions, shows a definite memory leak in scanning and updating the registry. Please see the attached valgrind log.
Please create a new valgrind log with the suppressions from common/gst.supp
The overwhelming majority of those aren't leaks (they're only created once by the GObject type system). The suppressions mentionned by Sebastian will trim off those false-positives.
Disabling the suppressions is what allowed me to see that there was a leak. Search for "definitely lost" and you'll see the trace for those items that need addressing. The records of interest, in particular, are: ==16686== 16 bytes in 1 blocks are definitely lost in loss record 2,488 of 5,357 ==16686== at 0x4022BF3: malloc (vg_replace_malloc.c:195) ==16686== by 0x42D6910: g_malloc (in /home/sysadmin/ossbuild/Shared/Build/Linux/x86/bin/libglib-2.0.so.0) ==16686== by 0x42F1CD4: g_memdup (in /home/sysadmin/ossbuild/Shared/Build/Linux/x86/bin/libglib-2.0.so.0) ==16686== by 0x40AA1EE: _priv_gst_registry_chunks_load_plugin (gstregistrychunks.c:775) ==16686== by 0x409A9D0: handle_rx_packet (gstpluginloader.c:773) ==16686== by 0x409B219: read_one (gstpluginloader.c:904) ==16686== by 0x409B3C8: exchange_packets (gstpluginloader.c:933) ==16686== by 0x4099188: plugin_loader_load (gstpluginloader.c:240) ==16686== by 0x40A5798: gst_registry_scan_plugin_file (gstregistry.c:1022) ==16686== by 0x40A6089: gst_registry_scan_path_level (gstregistry.c:1174) ==16686== by 0x40A615D: gst_registry_scan_path_internal (gstregistry.c:1193) ==16686== by 0x40A6CA9: scan_and_update_registry (gstregistry.c:1434) ==16686== 865 bytes in 27 blocks are definitely lost in loss record 5,276 of 5,357 ==16686== at 0x4022BF3: malloc (vg_replace_malloc.c:195) ==16686== by 0x42D6910: g_malloc (in /home/sysadmin/ossbuild/Shared/Build/Linux/x86/bin/libglib-2.0.so.0) ==16686== by 0x42F1CD4: g_memdup (in /home/sysadmin/ossbuild/Shared/Build/Linux/x86/bin/libglib-2.0.so.0) ==16686== by 0x40AA1EE: _priv_gst_registry_chunks_load_plugin (gstregistrychunks.c:775) ==16686== by 0x409A9D0: handle_rx_packet (gstpluginloader.c:773) ==16686== by 0x409B219: read_one (gstpluginloader.c:904) ==16686== by 0x409B3C8: exchange_packets (gstpluginloader.c:933) ==16686== by 0x4099188: plugin_loader_load (gstpluginloader.c:240) ==16686== by 0x40A5798: gst_registry_scan_plugin_file (gstregistry.c:1022) ==16686== by 0x40A6089: gst_registry_scan_path_level (gstregistry.c:1174) ==16686== by 0x40A615D: gst_registry_scan_path_internal (gstregistry.c:1193) ==16686== by 0x40A6F4C: scan_and_update_registry (gstregistry.c:1487) ==16686== 4,454 bytes in 130 blocks are definitely lost in loss record 5,319 of 5,357 ==16686== at 0x4022BF3: malloc (vg_replace_malloc.c:195) ==16686== by 0x42D6910: g_malloc (in /home/sysadmin/ossbuild/Shared/Build/Linux/x86/bin/libglib-2.0.so.0) ==16686== by 0x42F1CD4: g_memdup (in /home/sysadmin/ossbuild/Shared/Build/Linux/x86/bin/libglib-2.0.so.0) ==16686== by 0x40AA1EE: _priv_gst_registry_chunks_load_plugin (gstregistrychunks.c:775) ==16686== by 0x409A9D0: handle_rx_packet (gstpluginloader.c:773) ==16686== by 0x409B219: read_one (gstpluginloader.c:904) ==16686== by 0x409B3C8: exchange_packets (gstpluginloader.c:933) ==16686== by 0x4098EC5: plugin_loader_free (gstpluginloader.c:170) ==16686== by 0x40A55C2: clear_scan_context (gstregistry.c:990) ==16686== by 0x40A6F78: scan_and_update_registry (gstregistry.c:1492) ==16686== by 0x40A7358: ensure_current_registry (gstregistry.c:1560) ==16686== by 0x40A746E: gst_update_registry (gstregistry.c:1642)
Reopening because apparent leaks have been posted.
This should be fixed by this commit: commit c48591840558dc2517d4702d2e95771bfc4ef59c Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon Aug 23 10:58:16 2010 +0200 registrychunks: intern all GstPluginDesc members when unpacking