Re: Deadlock in Gst::init()

[Kurt Miller <kurt intricatesoftware com>]

On Sunday 13 May 2012 03:30:21 pm José Alburquerque wrote:
> On Sun, 2012-05-13 at 14:56 -0400, José Alburquerque wrote:
> > On Sat, 2012-05-12 at 13:52 -0400, Kurt Miller wrote:
> > > >>> Here is the stack trace showing the recursive call to
> > > >>> gst_plugin_load_by_name():
> > > >>> 
> > > >>> #2  0x0009c065 in _rthread_mutex_lock (mutexp=0x7c1e6670, trywait=0, abstime=0x0) at /usr/src/lib/librthread/rthread_sync.c:127
> > > >>> #3  0x08c68ec2 in g_mutex_lock () from /usr/local/lib/libglib-2.0.so.3200.0
> > > >>> #4  0x02f1f3e5 in gst_plugin_load_file (filename=0x7c1f6580 "/usr/local/lib/gstreamer-0.10/libgstadder.so", error=0xcfbc0bc8)
> > > >>>    at /usr/obj/ports/gstreamer-0.10.36/gstreamer-0.10.36/gst/gstplugin.c:722
> > > >>> #5  0x02f2022b in gst_plugin_load_by_name (name=0x7c3c2bf5 "adder") at /usr/obj/ports/gstreamer-0.10.36/gstreamer-0.10.36/gst/gstplugin.c:1297
> > > >>> #6  0x02f2185d in gst_plugin_feature_load (feature=0x7c3c32e8) at /usr/obj/ports/gstreamer-0.10.36/gstreamer-0.10.36/gst/gstpluginfeature.c:111
> > > >>> #7  0x0b5e3954 in gst_adder_get_type () at /usr/obj/ports/gstreamermm-0.10.10.1/gstreamermm-0.10.10.1/gstreamer/gstreamermm/adder.cc:29
> > > >>> #8  0x0ff679e1 in plugin_init (plugin=0x7c397d48) at /usr/obj/ports/gst-plugins-base-0.10.36/gst-plugins-base-0.10.36/gst/adder/gstadder.c:1322
> > > >>> #9  0x02f1e6ff in gst_plugin_register_func (plugin=0x7c397d48, desc=0x2ff66020, user_data=0x0)
> > > >>>    at /usr/obj/ports/gstreamer-0.10.36/gstreamer-0.10.36/gst/gstplugin.c:557
> > > >>> #10 0x02f1f611 in gst_plugin_load_file (filename=0x7c1f6580 "/usr/local/lib/gstreamer-0.10/libgstadder.so", error=0xcfbc0dc8)
> > > >>>    at /usr/obj/ports/gstreamer-0.10.36/gstreamer-0.10.36/gst/gstplugin.c:843
> > > >>> #11 0x02f2022b in gst_plugin_load_by_name (name=0x7c3c2bf5 "adder") at /usr/obj/ports/gstreamer-0.10.36/gstreamer-0.10.36/gst/gstplugin.c:1297
> > > >>> #12 0x02f2185d in gst_plugin_feature_load (feature=0x7c3c32e8) at /usr/obj/ports/gstreamer-0.10.36/gstreamer-0.10.36/gst/gstpluginfeature.c:111
> > > >>> #13 0x0b5e3954 in gst_adder_get_type () at /usr/obj/ports/gstreamermm-0.10.10.1/gstreamermm-0.10.10.1/gstreamer/gstreamermm/adder.cc:29
> > > >>> #14 0x0b624d21 in Gst::wrap_init () at /usr/obj/ports/gstreamermm-0.10.10.1/gstreamermm-0.10.10.1/gstreamer/gstreamermm/wrap_init.cc:386
> > > >>> #15 0x0b6258d0 in initialize_wrap_system () at /usr/obj/ports/gstreamermm-0.10.10.1/gstreamermm-0.10.10.1/gstreamer/gstreamermm/init.cc:36
> > > >>> #16 0x0b625a77 in Gst::init (argc=@0xcfbc0fb4, argv=@0xcfbc0fb8)
> > > >>>    at /usr/obj/ports/gstreamermm-0.10.10.1/gstreamermm-0.10.10.1/gstreamer/gstreamermm/init.cc:53
> > > >>> #17 0x1c01d13c in Glib::PropertyProxy<Glib::ustring>::get_value ()
> > > 
> > > I'm curious why frame 8 above doesn't end up going
> > > recursive on Linux like it does for OpenBSD. When I step through
> > > The code on OpenBSD it seems unavoidable.
> > 
> > It's difficult to know exactly what's happening.  On this system,
> > stepping through the code from frame 8 goes to line 119 of gstadder.c
> > which looks like the following:
> > 
> > GST_BOILERPLATE (GstAdder, gst_adder, GstElement, GST_TYPE_ELEMENT);
> > 
> > Apparently, this macro (defined in gstutils.h of GStreamer) generates
> > standard functions (among other things) for plug-ins such as the
> > *_get_type() functions (gst_adder_get_type() in this case).  The stack
> > trace below confirms this:
> > 
> > #0  g_once_init_enter(location = 0x7ffff31494e8) at gthread.c:674
> > #1  gst_adder_get_type() at gstadder.c:119
> > #2  plugin_init(plugin = 0x725e70) at gstadder.c:1322
> > #3  gst_plugin_register_func(plugin = 0x725e70, desc = 0x7ffff3149460,
> > user_data = 0x0) at gstplugin.c:557
> > #4  gst_plugin_load_file(filename = 0x734230
> > "/opt/usr-jhbuild/lib/gstreamer-0.10/libgstadder.so", error =
> > 0x7fffffffdd88) at gstplugin.c:843
> > #5  gst_plugin_load_by_name(name = 0x73333f "adder") at gstplugin.c:1297
> > #6  gst_plugin_feature_load(feature = 0x735480) at
> > gstpluginfeature.c:111
> > #7  gst_adder_get_type() at adder.cc:29
> > #8  Gst::wrap_init() at wrap_init.cc:384
> > #9  Gst::initialize_wrap_system() at init.cc:36
> > #10  Gst::init(argc = @0x7fffffffde9c: 2, argv = @0x7fffffffde90:
> > 0x7fffffffe028) at init.cc:53
> > #11  main(argc = 2, argv = 0x7fffffffe028) at hello_world/main.cc:67
> > 
> > On this system, the function that is called is gst_adder_get_type() in
> > gstadder.c (of the gst-plugins-base module) and not the one in adder.cc
> > (of gstreamermm).
> 
> As a test maybe someone could change the occurrences of
> gst_adder_get_type() in adder.cc and wrap_init.cc (of gstreamermm) to
> gst_adder_gstreamermm_get_type() (or something else), rebuild and run
> one of the tests (in tests/) or an example (such as the hello_world
> example) and see if that makes a difference.

Hi José,

Thanks for the ideas. Your thinking this is a symbol conflict, right? I tried
the rename of gst_adder_get_type() to gst_adder_mm_get_type() in
adder.cc and wrap_init.cc. This worked to get past the adder recursion,
however the same problem exists in next next plugin to be loaded:
audioconvert.

I'm now thinking this might be due to binutils 2.17 and later new feature:
-Bsymbolic-functions. Can you confirm if gst-plugins-base plugins are
linked with -Bsymbolic-functions? This would explain why the local
function is used over the one in gstreamermm.

Thanks,
-Kurt