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 88702 - gnomevfssrc, gstreamer, pipeline _READY -> segv
gnomevfssrc, gstreamer, pipeline _READY -> segv
Status: VERIFIED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.4.0
Other Linux
: Normal major
: 0.4.0
Assigned To: Bastien Nocera
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-07-20 20:55 UTC by rothwell
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
quickly hacked this up: seems to work for me (2.61 KB, text/plain)
2002-09-15 21:15 UTC, Jorn Baayen
Details

Description rothwell 2002-07-20 20:55:54 UTC
Situation:
Using gstreamer with gnomevfssrc in a simple pipeline (gnomevfssrc ! mad !
osssink ) inside a Gtk2 app. Platform is RedHat's "Limbo" beta release,
which includes Gnome2 and is built with gcc 3.1. Gcc 3.1 complains a lot
about -I/usr/include.

Reading the docs, toggling the pipeline from from _PLAYING to
_READY to _PLAYING seems like it should rewind the pipeline and start
playing again. However, gstreamer segfaults on _READY.

This does not happen with filesrc.

A similar thing happens with Monkey-Media (rhythmbox/monkey-sound), which
uses gstreamer and gnomevfssrc. 

This code ...

monkey_media_mixer_set_state (mixer, MONKEY_MEDIA_MIXER_STATE_STOPPED);

... segfaults. Presumably, it's setting the pipeline in gstreamer to _READY.
Comment 1 Jorn Baayen 2002-09-15 21:15:09 UTC
Created attachment 11092 [details]
quickly hacked this up: seems to work for me
Comment 2 Christian Fredrik Kalager Schaller 2002-09-15 21:16:18 UTC
ok,  Rothwell could you please try with current CVS and also check
jorns testcase it is seems to work now. 
Comment 3 rothwell 2002-09-18 13:45:55 UTC
I no longer get a segfault. I believe is was a double-close in the
gnomevfssrc module. Thanks!