Re: Deadlock in Gst::init()

[Kurt Miller <kurt intricatesoftware com>]

On Monday 14 May 2012 11:30:05 am Kurt Miller wrote:
> 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.

Hi José,

I think it should be reproduceable if you configure plugins-base
with --disable-Bsymbolic.

Thanks,
-Kurt