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 155814 - gst_bin_iterate() gets stuck on some images
gst_bin_iterate() gets stuck on some images
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.8.5
Other Linux
: Normal normal
: 0.8.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-10-19 11:50 UTC by Loïc Minier
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Loïc Minier 2004-10-19 11:50:22 UTC 
This bug has been reported against Rhythmbox in the first place, but it seems it
is a gstreamer parsing problem within the gst_bin_iterate() function.

When you add a music folder with some kind of images mixed with the audio files,
rhythmbox/gstreamer gets stuck.

See Bug#154909 for details.
Comment 1 Loïc Minier 2004-10-19 15:15:18 UTC 
works: gst-launch-0.8 filesrc location="music/tmp/Cover.jpg" ! typefind ! spider
! audio/x-raw-int ! fakesink

loops forever: gst-launch-0.8 gnomevfssrc location="music/tmp/Cover.jpg" !
typefind ! spider ! audio/x-raw-int ! fakesink

works: gst-launch-0.8 gnomevfssrc location="music/tmp/Cover.jpg" ! spider !
audio/x-raw-int ! fakesink
Comment 2 David Schleef 2004-10-26 05:39:34 UTC 
Works for me.  Does it fail with every file, or just some?
Comment 3 Loïc Minier 2004-10-26 08:09:55 UTC 
[I just noticed the version was set to HEAD CVS, I am in 0.8.7 from Debian sid]

Fails with every image file here.  Strangely, it always works with filesrc and
not with gnomevfssrc.  I tried with
location="file:///usr/share/pixmaps/gnome-laptop.png" too, but had no more success.

Here are two successive backtraces when the program is in its loop:
(gdb) thread apply all bt 5 full

+ Trace 51331

Thread 1 (Thread 1078515584 (LWP 18958))

  • #0 gst_debug_log_default
    from /usr/lib/libgstreamer-0.8.so.1
  • #1 gst_debug_log_valist
    from /usr/lib/libgstreamer-0.8.so.1
  • #2 gst_debug_log
    from /usr/lib/libgstreamer-0.8.so.1
  • #3 gst_data_unref
    from /usr/lib/libgstreamer-0.8.so.1
  • #4 gst_type_find_element_get_type
    from /usr/lib/gstreamer-0.8/libgstelements.so
  • #0 gst_debug_log_default
    from /usr/lib/libgstreamer-0.8.so.1

Thread 1 (Thread 1078515584 (LWP 18958))

  • #0 g_free
    from /usr/lib/libglib-2.0.so.0
  • #1 gst_debug_log_valist
    from /usr/lib/libgstreamer-0.8.so.1
  • #2 gst_debug_log
    from /usr/lib/libgstreamer-0.8.so.1
  • #3 gst_pad_push
    from /usr/lib/libgstreamer-0.8.so.1
  • #4 ??
    from /usr/lib/gstreamer-0.8/libgstoptscheduler.so 
(More stack frames follow...)
Comment 4 Loïc Minier 2004-10-27 08:40:15 UTC 
I think this is gone with CVS versions, I just built gstreamer and gst-plugins
and ran:
./tools/gst-launch --gst-plugin-path=../gst-plugins/ext/gnomevfs/.libs/
gnomevfssrc location="/usr/share/pixmaps/gnome-laptop.png" ! typefind ! spider !
audio/x-raw-int ! fakesink

I got:
ERROR: from element /pipeline0/typefindelement0: Could not determine type of stream.
ERROR (0x8050920 - 305240:36:33.978059000)       scheduler(28527)
gstoptimalscheduler.c(2609):gst_opt_scheduler_iterate:<GstOptScheduler@0x8059668>
in error state
Execution ended after 1 iterations (sum 2734000 ns, average 2734000 ns, min
2734000 ns, max 2734000 ns).

... which is good IMO, and I get the same result with filesrc.

I think you can close the bug (and you might want to release! :)
Comment 5 Sebastien Bacher 2004-10-28 14:29:14 UTC 
closed as asked by the submitter