After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 322708 - gst_plugin_load_file leaks a reference to a GstPlugin
gst_plugin_load_file leaks a reference to a GstPlugin
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal normal
: 0.9.7
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-11-29 00:13 UTC by Alessandro Decina
Modified: 2005-12-01 17:03 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Alessandro Decina 2005-11-29 00:13:38 UTC
Please describe the problem:
valgrind log:

==25221== 176 (16 direct, 160 indirect) bytes in 1 blocks are definitely lost in
loss record 3373 of 3724
==25221==    at 0x1B8FF896: malloc (vg_replace_malloc.c:149)
==25221==    by 0x1BAAA59F: g_malloc (in /usr/lib/libglib-2.0.so.0.900.0)
==25221==    by 0x1CEC4ABF: plugin_init (gsttypefindfunctions.c:1933)
==25221==    by 0x1B948622: gst_plugin_register_func (gstplugin.c:260)
==25221==    by 0x1B948B1F: gst_plugin_load_file (gstplugin.c:446)
==25221==    by 0x1B9492E2: gst_plugin_load_by_name (gstplugin.c:870)
==25221==    by 0x1B949746: gst_plugin_feature_load (gstpluginfeature.c:111)
==25221==    by 0x1B95F323: gst_type_find_factory_call_function
(gsttypefindfactory.c:230)
==25221==    by 0x1C1B2D1B: gst_ogg_type_find (gstoggdemux.c:2856)
==25221==    by 0x1C1AC5A0: gst_ogg_pad_typefind (gstoggdemux.c:785)
==25221==    by 0x1C1ACE67: gst_ogg_pad_submit_packet (gstoggdemux.c:969)
==25221==    by 0x1C1AD5E1: gst_ogg_pad_submit_page (gstoggdemux.c:1081)

I think the bug is at gstreamer/gst/gstplugin.c:465 (gst_plugin_load_file).
Before the gst_object_ref call, the plugin has refcount == 1;
then the refcount is incremented with gst_object_ref, so refcount == 2;
at line 466 gst_default_registry_add_plugin is called and the refcount is
incremented again (gstregistry.c:307), so refcount == 3;
gst_plugin_load_file then returns the plugin instance to gst_plugin_load_by_name
which in turn returns it to gst_plugin_feature_load;
in gst_plugin_feature_load (line 118) the refcount is correctly decremented only
once, so refcount == 2;
at the end the refcount is 2: one reference is held in the registry, the other
is leaked. 

Steps to reproduce:
for example by demuxing any ogg file (as oggdemux does typefinding/plugin loading)

Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Edward Hervey 2005-11-30 11:58:13 UTC
that leak is now fixed. It was in fact a leak with the GstTypeFindFactory
(gst_type_find_factory_call_function()).