Hello,
I am trying to get two of the same pipeline running in two separate threads (pthreads) in the same process. I seem to have bumped into a kind of race condition. This is what I get from the prompt: (testlib:20311): GLib-GObject-WARNING **: cannot register existing type `GstClock' (testlib:20311): GLib-GObject-WARNING **: gtype.c:3340: type id `0' is invalid (testlib:20311): GLib-GObject-WARNING **: can't peek value table for type `<invalid>' which is not currently referenced (testlib:20311): GLib-GObject-WARNING **: gvalue.c:96: cannot initialize GValue with type `(null)', this type has no GTypeValueTable implementation (testlib:20311): GLib-GObject-WARNING **: gtype.c:3340: type id `0' is invalid (testlib:20311): GLib-GObject-WARNING **: can't peek value table for type `<invalid>' which is not currently referenced Fallo de segmentación (core dumped) And the core file says: Core was generated by `./testlib'. Program terminated with signal 11, Segmentation fault. #0 0xb7f4c1d6 in gst_structure_set_valist (structure=0x819fa28, fieldname=0xb7f783a4 "clock", varargs=0xb69c31b8 "") at gststructure.c:528 528 G_VALUE_COLLECT (&field.value, varargs, 0, &err); (gdb) bt #0 0xb7f4c1d6 in gst_structure_set_valist (structure=0x819fa28, fieldname=0xb7f783a4 "clock", varargs=0xb69c31b8 "") at gststructure.c:528 #1 0xb7f4e3be in gst_structure_new_valist (name=0xb7f7cf25 "GstMessageClockProvide", firstfield=0xb7f783a4 "clock", varargs=0xb69c31b8 "") at gststructure.c:239 #2 0xb7f4e422 in gst_structure_new (name=0x0, firstfield=0xb7f783a4 "clock") at gststructure.c:209 #3 0xb7f338bb in gst_message_new_clock_provide (src=0x80db6f0, clock=0x0, ready=1) at gstmessage.c:535 #4 0xb7f1138c in gst_bin_add_func (bin=0x80db600, element=0x80db6f0) at gstbin.c:906 #5 0xb7f0e4aa in gst_bin_add (bin=0x80db600, element=0x80db6f0) at gstbin.c:1038 #6 0xb7f5a79e in gst_bin_add_many (bin=0x80db600, element_1=0x80db6f0) at gstutils.c:2207 #7 0x0806889f in playerSimpleCreate (fP=0x80dc488, noPort1=0, noPort2=0, input=0x80dc5d8 "/home/demo/media/videos/toyota.mpg", bitrate=0, sourceType=0x80dc7e8 "filesrc", nada2=0) at playerSimple.c:416 #8 0x08056fe4 in flowPipelineCreate (flowP=0x80dc488) at vicoFlow.c:150 #9 0x0805733e in vicoFlowInit (flowP=0x80dc488) at vicoFlow.c:202 #10 0x0805634a in vicoRun (arg=0x80dc488) at vico.c:609 #11 0xb7cc046b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #12 0xb7c446de in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) I think this is because the two threads try too create their pipeline at the same time and Glibs hashtable of types does not reflect upon this. Or maybe there should be a mutex in the gstreamer level? So ifdeffing in the function check_type_name_I() in gtype.c the code the problem does not occur: #if 0 if (g_type_from_name (type_name)) { g_warning ("cannot register existing type `%s'", type_name); return FALSE; } #endif So whats the right way to go about this? Does the gstreamer/glib framework really support mutlithreaded applications?ç Thank you, Mattias ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
On Fri, 2008-04-25 at 11:02 +0200, Mattias Barthel wrote:
> I am trying to get two of the same pipeline running in two separate > threads (pthreads) in the same process. > I seem to have bumped into a kind of race condition. > This is what I get from the prompt: > > (testlib:20311): GLib-GObject-WARNING **: cannot register existing type > `GstClock' > (testlib:20311): GLib-GObject-WARNING **: gtype.c:3340: type id `0' is > invalid > (snip) > > I think this is because the two threads try too create their pipeline at > the same time and Glibs hashtable of types does not reflect upon this. > Or maybe there should be a mutex in the gstreamer level? It's a bug in GLib. This is fixed in GLib-2.16 as far as I know. We do try to work around this in GStreamer though, so if you run into issues like this, please file a bug in bugzilla so we can fix it. I've recently fixed a few of these problems in core and -base CVS, so you might want to upgrade. Cheers -Tim ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Tim Müller wrote:
> On Fri, 2008-04-25 at 11:02 +0200, Mattias Barthel wrote: > > >> I am trying to get two of the same pipeline running in two separate >> threads (pthreads) in the same process. >> I seem to have bumped into a kind of race condition. >> > > >> This is what I get from the prompt: >> >> (testlib:20311): GLib-GObject-WARNING **: cannot register existing type >> `GstClock' >> (testlib:20311): GLib-GObject-WARNING **: gtype.c:3340: type id `0' is >> invalid >> (snip) >> >> I think this is because the two threads try too create their pipeline at >> the same time and Glibs hashtable of types does not reflect upon this. >> Or maybe there should be a mutex in the gstreamer level? >> > > It's a bug in GLib. This is fixed in GLib-2.16 as far as I know. > > We do try to work around this in GStreamer though, so if you run into > issues like this, please file a bug in bugzilla so we can fix it. > > I've recently fixed a few of these problems in core and -base CVS, so > you might want to upgrade. > > Cheers > -Tim > > > I am using gstreamer 0.10.18, could this be an issue? Thanks, Mattias ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
On Mon, 2008-04-28 at 10:29 +0200, Mattias Barthel wrote:
> I upgraded to 2.16.3 but still the problem remains. Right, I think there are two types of issues, one in GLib with class creation (which should be fixed in 2.16 AFAIK) and one with some of our _get_type() functions. Since we have to work around the former anyway for the time being there's little point in fixing up the latter quite yet. > I am using gstreamer 0.10.18, could this be an issue? Yes. Please try core/base CVS, a whole bunch of these issues have been fixed recently. Cheers -Tim ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Am Montag, den 28.04.2008, 10:30 +0100 schrieb Tim Müller:
> On Mon, 2008-04-28 at 10:29 +0200, Mattias Barthel wrote: > > > I upgraded to 2.16.3 but still the problem remains. > > Right, I think there are two types of issues, one in GLib with class > creation (which should be fixed in 2.16 AFAIK) and one with some of our > _get_type() functions. Since we have to work around the former anyway > for the time being there's little point in fixing up the latter quite > yet. What is the issue with our get_type() functions? From what I understood the fix in GLib makes it unnecessary to wrap everything in g_once_init stuff. > > I am using gstreamer 0.10.18, could this be an issue? > > Yes. Please try core/base CVS, a whole bunch of these issues have been > fixed recently. I've fixed one of his issues earlier today, which was that GstClock wasn't registred from a type-safe context. With this and all the _class_ref()s we have in core CVS it seems to work fine. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel signature.asc (196 bytes) Download Attachment |
Sebastian Dröge wrote:
> Am Montag, den 28.04.2008, 10:30 +0100 schrieb Tim Müller: > >> On Mon, 2008-04-28 at 10:29 +0200, Mattias Barthel wrote: >> >> >>> I upgraded to 2.16.3 but still the problem remai >>> ns. >>> >> Right, I think there are two types of issues, one in GLib with class >> creation (which should be fixed in 2.16 AFAIK) and one with some of our >> _get_type() functions. Since we have to work around the former anyway >> for the time being there's little point in fixing up the latter quite >> yet. >> > > What is the issue with our get_type() functions? From what I understood > the fix in GLib makes it unnecessary to wrap everything in g_once_init > stuff. > > >>> I am using gstreamer 0.10.18, could this be an issue? >>> >> Yes. Please try core/base CVS, a whole bunch of these issues have been >> fixed recently. >> > > I've fixed one of his issues earlier today, which was that GstClock > wasn't registred from a type-safe context. With this and all the > _class_ref()s we have in core CVS it seems to work fine. > > The thing is, I still use GLib 2.16.3, so it does not seem to be fixed there. Thanks, Mattias ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
In reply to this post by Sebastian Dröge
On Mon, 2008-04-28 at 12:50 +0200, Sebastian Dröge wrote:
> > Right, I think there are two types of issues, one in GLib with class > > creation (which should be fixed in 2.16 AFAIK) and one with some of our > > _get_type() functions. Since we have to work around the former anyway > > for the time being there's little point in fixing up the latter quite > > yet. > > What is the issue with our get_type() functions? From what I > understood the fix in GLib makes it unnecessary to wrap everything in > g_once_init stuff. If I remember correctly there are at least two issues: (a) racy _get_type() functions: GType foo_bar_get_type() { static GType mytype = 0; if (mytype == 0) { mytype = g_type_register (...); } return mytype; } This, when called from two threads at the same time, will lead to 'Cannot register existing type FooBar' warnings from GLib, which are annoying, but -- at least as far as I know -- harmless, since the underlying GLib code does do proper locking. The race condition here is that 'mytype' is not being protected by a mutex, so there's nothing GLib can do about this. The GOnce stuff in connection with the _get_type() functions fixes this race condition and avoids the warnings. (b) class creation isn't/wasn't thread-safe in GLib This is the infamous http://bugzilla.gnome.org/show_bug.cgi?id=64764 (proxied in GStreamer as #349410 and #474823 and others). This is what the g_class_ref() works around and what is fixed in GLib-2.16. > From what I understood the fix in GLib makes it unnecessary to wrap > everything in g_once_init stuff. I think the GOnce stuff for the _get_type() functions is still needed, unless GLib dropped the 'existing type' warning and silently returns the existing type now - doesn't look like it from the code in trunk though. Cheers -Tim ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |