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 668713 - Seek -> Crash. URIDecodeBin & AppSink
Seek -> Crash. URIDecodeBin & AppSink
Status: RESOLVED DUPLICATE of bug 620099
Product: gnome-perl
Classification: Bindings
Component: GStreamer
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk2-perl-bugs
gtk2-perl-bugs
Depends on:
Blocks:
 
 
Reported: 2012-01-26 06:17 UTC by Zach Morgan
Modified: 2012-02-20 04:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
one of many different sorts of crashes. (7.08 KB, text/x-log)
2012-01-26 06:17 UTC, Zach Morgan
Details
A much simpler crasher script (12.38 KB, text/plain)
2012-01-27 00:53 UTC, Zach Morgan
Details
Seeking crash.pl (4.09 KB, text/plain)
2012-02-19 20:16 UTC, Torsten Schoenfeld
Details
It keeps happening (25.90 KB, text/plain)
2012-02-20 04:24 UTC, Zach Morgan
Details

Description Zach Morgan 2012-01-26 06:17:03 UTC
Created attachment 206156 [details]
one of many different sorts of crashes.

Howdy,

I've struggled with gstreamer crashes for a few days, trying to dump raw audio data after calling seek(). It always crashes, and I can't figure out why. I'm hoping that it's obvious to someone else. I'm using 0.16 from cpan, but it looks like it hasn't been altered since 0.16.

This problem is independent of the GStreamer::App module that I was working on. It turns out that its API is somehow implemented with signals, so it wouldn't even be useful.

I've tagged my project in a state where it crashes every time it is used a certain way:
https://github.com/zpmorgan/PDL-GStreamer/tree/unknown-fail

To make it crash, run the following with an audio file $FILE
perl examples/spectrogram.pl $FILE
Comment 1 Zach Morgan 2012-01-27 00:53:55 UTC
Created attachment 206229 [details]
A much simpler crasher script

Earlier I pointed to my own git repository, which involved PDL as a requirement. Sorry about that.

Here's a script that only uses GStreamer. After having an appsink pull a buffer, the buffer is mysteriously erased, and other variables, such as $pipeline, are mysteriously changed.

Seeking does not work at all, but I'm not totally convinced that this is perl-gstreamer's fault. The same seek works, however, when the pipeline is a playbin2.

To run as it is, a foo.mp3 audio file is required in the same directory as crash.pl.

Thanks,
Zach Morgan
Comment 2 Quentin Sculo 2012-01-31 16:37:28 UTC
I haven't really looked at what crash.pl is doing, but I suspected that it would be affected by the gstreamer foreign threads problem from bug 620099 (https://bugzilla.gnome.org/show_bug.cgi?id=620099)
And the patch from this bug does seem to fix crash.pl so it is possible that it is the same bug.
Comment 3 Torsten Schoenfeld 2012-02-19 15:28:30 UTC
(In reply to comment #1)
> Here's a script that only uses GStreamer. After having an appsink pull a
> buffer, the buffer is mysteriously erased, and other variables, such as
> $pipeline, are mysteriously changed.

As Quentin said, this is indeed due to some signals (pad-added, new-buffer) being invoked from a foreign thread, for which Glib was not yet prepared.  I just committed <http://git.gnome.org/browse/perl-Glib/commit/?id=6f1bc1a56e4c7c87d44caca1001cd50357f7a603> the fix mentioned in the other bug, which does indeed also seem to solve your problem.  Please test extensively.

*** This bug has been marked as a duplicate of bug 620099 ***
Comment 4 Zach Morgan 2012-02-19 19:12:39 UTC
Does crash.pl work for you? there has to be a foo.mp3 in the same directory. Unfortunately it still crashes every time I run it, after playing a second of audio. The crashes are just as inconsistent as before.

I'm completely clueless as to what's going on. Is there any way I can help? I'm running 5.15 with perlbrew, Glib bindings & GStreamer bindings from your git repositories. Also, the libraries (not the bindings) are from the Ubuntu 6.06 repositories.

(just kidding. glib & gstreamer libraries are from ubuntu 12.04.)

Thanks,
Zach Morgan
Comment 5 Torsten Schoenfeld 2012-02-19 20:15:19 UTC
Well, it kind of works, yes.  It pipes one second of music¹ to pacat.  Then it hangs.  I think that's because you try to reuse all the elements for a second run (the second signal_connect() calls will be a problem, for example).  Seeking doesn't work like you try to do it; seek() is not instantaneous.  The normal procedure:

• put your pipeline into "paused" (or "playing"),
• watch the message bus for when the pipeline has actually transitioned into "paused" (or "playing"), then seek() and set_state("playing")

<http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-eventsseek.html>.

I attach a version of crash.pl that works for me.

¹ Or at least a version of it, apparently missing many frequencies, especially the low ones, and also with a slower tempo.
Comment 6 Torsten Schoenfeld 2012-02-19 20:16:15 UTC
Well, it kind of works, yes.  It pipes one second of music¹ to pacat.  Then it hangs.  I think that's because you try to reuse all the elements for a second run (the second signal_connect() calls will be a problem, for example).  Seeking doesn't work like you try to do it; seek() is not instantaneous.  The normal procedure:

• put your pipeline into "paused" (or "playing"),
• watch the message bus for when the pipeline has actually transitioned into "paused" (or "playing"), then seek() and set_state("playing")

<http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-eventsseek.html>.

I attach a version of crash.pl that works for me.

¹ Or at least a version of it, apparently missing many frequencies, especially the low ones, and also with a slower tempo.
Comment 7 Torsten Schoenfeld 2012-02-19 20:16:56 UTC
Created attachment 208002 [details]
Seeking crash.pl
Comment 8 Zach Morgan 2012-02-20 04:24:59 UTC
Created attachment 208021 [details]
It keeps happening

It still fails. I suppose this means that this problem doesn't affect everyone. Maybe it's not related to bug 620099. Your thoughts?