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 349410 - Problems with type handling
Problems with type handling
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.10.15
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 354139 356943 357277 371396 373160 376389 377801 378423 378434 379287 391569 392029 394001 395861 396755 402077 412498 413668 414410 415367 416086 416431 416448 419937 420874 463538 493432 (view as bug list)
Depends on: 64764
Blocks: 474823
 
 
Reported: 2006-07-31 10:32 UTC by Jan Schmidt
Modified: 2008-02-05 20:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jan Schmidt 2006-07-31 10:32:09 UTC
Filing this bug so I don't forget about it.

Revision 1.8 of tests/check/pipelines/parse-launch.c in GStreamer core causes intermittent errors, on multi-core machines at least. I can't reproduce the problem on a single core machine.

It manifests in a couple of different ways, that centre around serialisation of an enum:

Running suite(s): Parse Launch syntax
GLib-GObject-ERROR **: g_type_plugin_*() invalidly modified type `GstFormat'
aborting...

OR

Running suite(s): Parse Launch syntax
GLib-GObject-ERROR **: file gtype.c: line 1809 (type_class_init_Wm): assertion failed: (node->is_classed && node->data && node->data->class.class_size && !node->data->class.class && node->data->class.init_state == UNINITIALIZED)
aborting...

Grabbing a backtrace shows:

Thread 5 (process 19704)

  • #0 __lll_mutex_lock_wait
    from /lib/libpthread.so.0
  • #1 ??
  • #2 ??

Thread 3 (process 19707)

  • #0 __lll_mutex_lock_wait
    from /lib/libpthread.so.0
  • #1 pthread_mutex_destroy
    from /lib/libpthread.so.0
  • #2 ??
  • #3 pthread_mutex_lock
    from /lib/libpthread.so.0
  • #4 ??

Thread 2 (process 19708)

  • #0 clone
    from /lib/libc.so.6
  • #1 __free_tcb
    from /lib/libpthread.so.0
  • #2 ??
  • #3 ??

The fault seems to lie inside GLib somewhere. I suspect it is failing when 2 threads simultaneously increment the refcount of a class, possibly because it is the first access to the type. The GstFormat type itself is registered inside gst_init, but no instance is created until and the class is unused except for GstValue transformations afaics.

Changing the tests to have silent=true for fakesink and identity masks the problem by avoiding serialisation of NewSegment events.
Comment 1 Tim-Philipp Müller 2006-09-04 10:42:17 UTC
*** Bug 354139 has been marked as a duplicate of this bug. ***
Comment 2 Karsten Bräckelmann 2006-09-20 18:27:13 UTC
*** Bug 356943 has been marked as a duplicate of this bug. ***
Comment 3 Karsten Bräckelmann 2006-09-23 03:29:52 UTC
*** Bug 357277 has been marked as a duplicate of this bug. ***
Comment 4 Antoine Tremblay 2006-10-18 18:49:08 UTC
I had this kind of problem too see : http://bugzilla.gnome.org/show_bug.cgi?id=64764

and : http://bugzilla.gnome.org/show_bug.cgi?id=65041

Seems like we would have to rewrite our get_type functions to work with g_once and patch glib
Comment 5 Karsten Bräckelmann 2006-11-06 14:11:39 UTC
*** Bug 371396 has been marked as a duplicate of this bug. ***
Comment 6 Jan Schmidt 2006-11-06 16:23:27 UTC
My worry with GOnce is cost - the cost after initialisation should be VERY low, because these get_type methods are called a lot. 

That is, they should only involve a memory barrier if the value is not yet set.
Comment 7 Antoine Tremblay 2006-11-06 16:46:28 UTC
That will be the case , see the end of   http://bugzilla.gnome.org/show_bug.cgi?id=65041

I will implement _enter and _leave in gstreamer while glib doesn't have it and then check for the version to enable it from glib...

Note that this does not solve the class ref problem : http://bugzilla.gnome.org/show_bug.cgi?id=64764

But it does solve the get_type ...
Comment 8 Jan Arne Petersen 2006-11-22 09:56:13 UTC
*** Bug 376389 has been marked as a duplicate of this bug. ***
Comment 9 Jan Arne Petersen 2006-11-22 09:56:21 UTC
*** Bug 373160 has been marked as a duplicate of this bug. ***
Comment 10 Jan Arne Petersen 2006-11-22 09:56:29 UTC
*** Bug 377801 has been marked as a duplicate of this bug. ***
Comment 11 Jens Granseuer 2006-11-25 22:29:32 UTC
*** Bug 378423 has been marked as a duplicate of this bug. ***
Comment 12 Jens Granseuer 2006-11-25 22:30:29 UTC
*** Bug 378434 has been marked as a duplicate of this bug. ***
Comment 13 Jens Granseuer 2006-11-25 22:30:51 UTC
*** Bug 379287 has been marked as a duplicate of this bug. ***
Comment 14 Jens Granseuer 2007-01-13 13:34:28 UTC
*** Bug 395861 has been marked as a duplicate of this bug. ***
Comment 15 André Klapper 2007-01-17 01:27:45 UTC
*** Bug 396755 has been marked as a duplicate of this bug. ***
Comment 16 André Klapper 2007-01-17 01:27:53 UTC
*** Bug 394001 has been marked as a duplicate of this bug. ***
Comment 17 André Klapper 2007-01-17 01:28:01 UTC
*** Bug 392029 has been marked as a duplicate of this bug. ***
Comment 18 André Klapper 2007-01-17 01:28:08 UTC
*** Bug 391569 has been marked as a duplicate of this bug. ***
Comment 19 Jan Schmidt 2007-03-02 17:39:53 UTC
How's progress on getting this stuff into GLib, Antoine?
Comment 20 Antoine Tremblay 2007-03-02 21:43:32 UTC
Still waiting for Tim to awnser see : http://bugzilla.gnome.org/show_bug.cgi?id=65041

I just pinged him again...

Comment 21 André Klapper 2007-03-11 14:18:13 UTC
*** Bug 402077 has been marked as a duplicate of this bug. ***
Comment 22 André Klapper 2007-03-11 14:18:22 UTC
*** Bug 412498 has been marked as a duplicate of this bug. ***
Comment 23 André Klapper 2007-03-11 14:18:28 UTC
*** Bug 413668 has been marked as a duplicate of this bug. ***
Comment 24 André Klapper 2007-03-11 14:18:32 UTC
*** Bug 414410 has been marked as a duplicate of this bug. ***
Comment 25 André Klapper 2007-03-11 14:19:08 UTC
*** Bug 416086 has been marked as a duplicate of this bug. ***
Comment 26 André Klapper 2007-03-11 14:19:13 UTC
*** Bug 416431 has been marked as a duplicate of this bug. ***
Comment 27 André Klapper 2007-03-11 14:19:17 UTC
*** Bug 416448 has been marked as a duplicate of this bug. ***
Comment 28 André Klapper 2007-03-11 14:19:43 UTC
*** Bug 415367 has been marked as a duplicate of this bug. ***
Comment 29 André Klapper 2007-03-29 02:50:37 UTC
*** Bug 420874 has been marked as a duplicate of this bug. ***
Comment 30 André Klapper 2007-03-29 02:50:44 UTC
*** Bug 419937 has been marked as a duplicate of this bug. ***
Comment 31 Philip Withnall 2007-08-08 23:17:19 UTC
*** Bug 463538 has been marked as a duplicate of this bug. ***
Comment 32 Tim-Philipp Müller 2007-11-14 16:41:49 UTC
This is hilarious - it's the exact same issue as the intermittent tee unit test failures we observed recently (bug #474823), only that it's been open for more than 2 years ...

In any case, this works around the issue in GLib/GObject on our side:

 2007-11-01  Tim-Philipp Müller  <tim at centricular dot net>

        * gst/gst.c: (init_post):
        * gst/gstevent.c: (_gst_event_initialize):
        * gst/gstquery.c: (_gst_query_initialize):
        * libs/gst/dataprotocol/dataprotocol.c (gst_dp_init):
          g_type_class_ref() other types as well, see #349410 and #64764.

        * gst/gstbuffer.c: (_gst_buffer_initialize):
        * gst/gstmessage.c: (_gst_message_initialize):
          Simplify existing g_type_class_ref().

 2007-11-01  Tim-Philipp Müller  <tim at centricular dot net>

        * gst/gstformat.c: (_gst_format_initialize):
          g_type_class_ref() our GstFormat type to make sure we avoid the
          thread-unsafe bits of the GObject/GType system, ie. bug #349410 and
          bug #64764. Should fix intermittent tee unit test failures (#474823).

No point in keeping this bug open any longer IMO, given that there's a bug for GLib already.
Comment 33 Tim-Philipp Müller 2008-01-10 17:25:36 UTC
*** Bug 493432 has been marked as a duplicate of this bug. ***
Comment 34 Antoine Tremblay 2008-01-10 18:51:27 UTC
Note that the glib side of this is now fixed it's in 2.14.5

We should use g_once_init_enter and _leave...

I've been meaning to do this for a long while... seems like I failed to find the time/motivation... sorry :(

We should publicize this to the gstreamer devs.. and make a basic _enter , _leave for compatibility with glib versions < 2.14.5...

Note also that the other bug concerting class_ref thread safety is still open so this kind of crash will still happen for a while even with these changes.. but it's still a step in the right direction...




Comment 35 Antoine Tremblay 2008-01-10 18:55:41 UTC
Just realized  that _enter and _leave is in Glib since : 2.13.7

Comment 36 Tim-Philipp Müller 2008-01-10 19:11:52 UTC
> Note that the glib side of this is now fixed it's in 2.14.5
> We should use g_once_init_enter and _leave...

That's just for the GType registration, I think (which we've been doing from a thread-safe context for a long time).


> Note also that the other bug concerting class_ref thread safety is still open
> so this kind of crash will still happen for a while even with these changes..
> but it's still a step in the right direction...

I don't think it will happen with these changes. Why do you think it will?
 

Comment 37 Antoine Tremblay 2008-01-10 19:26:53 UTC
>That's just for the GType registration, I think (which we've been doing from a
>thread-safe context for a long time).

It's for GType registrations yes,, but not everything was in a thread-safe context.. Most basic types of gstreamer are but for example everything that is in a plugin is not, and I think there's still some basic types in the base libs that are not...

First thing would be to have this in the BOILERPLATE 

>I don't think it will happen with these changes. Why do you think it will?

It will.. I tested a lot and it could really happen anywhere.. granted the basic types were the most common issue but it can happen really anywhere especially in the plugin inits... so the boilerplate should include this for sure. 

I'm just not sure how to add _once _leave to keep compatitiblity with earlyer versions of Glib.. maybe with a __weak__ symlink... or checking with pkg-config and enabling the correct code...



Comment 38 Antoine Tremblay 2008-01-10 19:33:21 UTC
Rereading myself I found that maybe I was a bit confusing.. the class_ref issue will happen even with _once and _leave ... and it will happen even with the basic types reffed in a single thread state... It will just happen with other types... since there are all affected..  :( 

Note that using the last patch in http://bugzilla.gnome.org/show_bug.cgi?id=64764
fixed the issue for me...

Maybe we should revive this issue in glib... and have that patch checked more seriously 

Comment 39 Antoine Tremblay 2008-02-05 20:21:31 UTC
Just a note to say that Bug #64764 concerning the class_ref issue is fixed now