GNOME Bugzilla – Bug 329198
GStreamer-CRITICAL: gst_pad_activate_pull: assertion `old == GST_ACTIVATE_NONE' failed
Last modified: 2006-07-09 13:26:23 UTC
Steps to reproduce: 1. run cvs gstreamer with latest gtk/glib cvs 2. 3. Stack trace: [Thread 163844 (LWP 7587) exited] [New Thread 229384 (LWP 7591)] [New Thread 245764 (LWP 7592)] [New Thread 262153 (LWP 7593)] GStreamer-CRITICAL **: gst_pad_activate_pull: assertion `old == GST_ACTIVATE_NONE' failed aborting... Program received signal SIGTRAP, Trace/breakpoint trap.
+ Trace 65741
Thread 16386 (LWP 7554)
Other information:
Probably a prob in gstreamer CVS. Looks like it dies trying to read a particular ID3-tagged file. Can you provide the file (if short) or some information about it? Can you try an empty library, e.g. rhythmbox --rhythmdb-file=/tmp/rhythmdb.xml and just add files progressively until you see the crash. It would be interesting to see if OGG files had similar problems.
(In reply to comment #1) Also running it with the "-d" debug flag might also help: > rhythmbox -d --rhythmdb-file=/tmp/rhythmdb.xml
This isn't actually a crash. GStreamer is emitting a critical warning, and the reporter is using jhbuild (or similar) which, since the start of the year, makes all critical warnings fatal. Since this is in GStreamer's id3mux plugin, moving there.
Created attachment 58391 [details] Better stack Looks like it always happens with a broken mp3 file...
Yeah, I've seen this too - it happens on any file that has ID3 information, but where GStreamer can't detect the type within ID3 (broken mp3 files, as Mitch says, among others) I'm not quite sure where the failure is in the chain of events, but it goes something like this: decodebin detects that the file contains ID3 tags and connects id3demux id3demux reads the id3 tag(s) and then attempts to determine the type of the file within the id3 tag(s). It can't detect the type, sends an error message, and returns FALSE from the pad activation. Decodebin ignores the error that id3demux didn't change state and continues on. It doesn't have any more dynamic elements, so completes its state change. The typefind element switches to PUSH mode. As decodebin proceeds to state PAUSED, the core attempts to activate the id3demux pads again, causing id3demux to attempt to activate PULL mode on typefind's src pad, which fails because typefind is already in push mode. There are a couple of places in this sequence where things aren't working perfectly, I'm just not sure what it SHOULD like so I can't fix it.
(Jan should start confirming bugs :)
What's confirming?
Changing the status from UNCONFIRMED to NEW
*** Bug 330058 has been marked as a duplicate of this bug. ***
I can see this with a truncated file as well (d&d it into rhythmbox or use nautilus to show its properties) however easytag reads the file just fine and seems to detect sane information. (id3 information if I am not mistaken)
I was in error, it filled in save information. I saved them into the .mp3 file and it crashes no longer when importing so this is indeed the cause
*** Bug 332392 has been marked as a duplicate of this bug. ***
Created attachment 61089 [details] file to reproduce the problem with Attaching a file that reproduces the problem. Use like gst-launch-0.10 playbin uri=file:///path/to/random-data-with-id3.data
* gst/gstpad.c: (gst_pad_init), (gst_pad_activate_pull), (gst_pad_activate_push): Use some more macros where it makes sense. Allow pad mode switching instead of asserting. When a pad is activated in one mode and we activate it in another, deactivate it first before activating it in a different mode. Fixes #329198.