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 309122 - can't dismantle element group: scheduler/opt says: assertion failed: (group->group_links == NULL)
can't dismantle element group: scheduler/opt says: assertion failed: (group->...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.8.10
Other Linux
: Normal critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-06-27 11:41 UTC by Akos Maroy
Modified: 2005-11-30 13:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
output of the program running, with --gst-debug-level=5 (85.02 KB, application/bzip2)
2005-06-27 11:43 UTC, Akos Maroy
Details
sample code demonstrating the problem (11.03 KB, text/plain)
2005-06-28 13:48 UTC, Akos Maroy
Details

Description Akos Maroy 2005-06-27 11:41:42 UTC
when trying to dismantle a specific element group, containing oggdemux and
vorbisdec elements, I can't, as no matter how I try to get rid of the group, I get:

** ERROR **: file gstoptimalscheduler.c: line 882 (destroy_group): assertion
failed: (group->group_links == NULL)

I got the suggestion that trying to play around with the order elements are
unlinked and removed would help. but it doesn't.
Comment 1 Akos Maroy 2005-06-27 11:43:49 UTC
Created attachment 48409 [details]
output of the program running, with --gst-debug-level=5
Comment 2 Akos Maroy 2005-06-28 13:48:32 UTC
Created attachment 48446 [details]
sample code demonstrating the problem

see this sample that demonstrates the problem. when run with an Ogg Vorbis
input file, I get the error:

** ERROR **: file gstoptimalscheduler.c: line 871 (destroy_group): assertion
failed: (group->group_links == NULL)

when run with an mp3 input file, there's no error.

I found that the issue comes up when using an N-to-1 element, such as the
switch (but other elements bring up the issue as well)
Comment 3 Akos Maroy 2005-06-28 13:50:41 UTC
as a workaround, if the following two blocks:

    gst_element_link(filter, sink);
    gst_bin_add_many(GST_BIN(pipeline), filter, sink, NULL);

    gst_element_link(decoder, filter);
    gst_bin_add_many(GST_BIN(pipeline), source, decoder, NULL);

are reversed in order (first the decoder and the filter is linked), the assert
is not thrown.

this all looks very strange...
Comment 4 Mark Kretschmann 2005-09-09 16:51:14 UTC
Note: This bug only affects alsasink. It does not happen with any other sink, 
e.g. osssink. So I suspect that it's a bug in alsasink itself. 
 
Comment 5 Andy Wingo 2005-11-30 13:05:49 UTC
Probably not alsasink itself, just that it is scheduled differently (loop-based
rather than chain-based). In any case everyone who groks the scheduler now hacks
0.10, where issues like this don't exist. Closing as obsolete.