Gtype registration error

[Mattias Barthel]

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

[Tim-Philipp Müller-2]

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

[Mattias Barthel]

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 upgraded to 2.16.3 but still the problem remains.
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

[Tim-Philipp Müller-2]

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

[Sebastian Dröge]

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

[Mattias Barthel]

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.
>  
>  

Yes, I confirm that.
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

[Tim-Philipp Müller-2]

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