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 121267 - Streaming oggs makes gst (spider?) crash
Streaming oggs makes gst (spider?) crash
Status: VERIFIED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.6.3
Other Linux
: High critical
: 0.8.0
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-09-02 14:16 UTC by 092222
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description 092222 2003-09-02 14:16:25 UTC
Distribution: Debian testing/unstable
(This bug report was generated by Bug Buddy 2.3.4)
Description:
Description of the crash:
When playing a oggfile from the network, gst crashes. Plaing mp3s from
the same location works, and playing the ogg from a file:-url works

Steps to reproduce the crash:
run gst-launch gnomevfssrc "location=<URL-to streaming ogg>"  ! spider !
volume ! osssink sync=false

I have reprodused the bug with libapache-mod-mp3 on my localhost and
with diffrent servers on internet (virgin radio
http://ogg.smgradio.com/lq32.ogg streamingsoundtracks.com etc.)

Expected Results:
Music in my ears :-)

How often does this happen?
everytime.

Traceback:
INFO (31335: 0) Initializing GStreamer Core Library version 0.6.3
INFO (31335: 0) CPU features: (0c040882) MMX SSE
INFO (31335: 0) registry: loaded user_registry in 0.000288 seconds
          (/home/jens/.gstreamer/registry.xml)
INFO (31335: 0) registry: loaded global_registry in 0.361479 seconds
         
(/home/garnome/garnome-26/var/cache/gstreamer-0.6/registry.xml)
GStreamer-INFO: 0 live buffer(s)
GStreamer-INFO: 0 live bufferpool(s)
GStreamer-INFO: 0 live event(s)
RUNNING pipeline
Caught SIGSEGV accessing address 0x62696c33
  • #0 wait4
    from /lib/libc.so.6
  • #1 sys_sigabbrev
    from /lib/libc.so.6
  • #2 wait
    from /lib/libpthread.so.0
  • #3 fault_handler
  • #4 __pthread_sighandler_rt
    from /lib/libpthread.so.0
  • #5 sigaction
    from /lib/libc.so.6
  • #6 gst_type_type_find_dummy
  • #7 gst_spider_identity_sink_loop_type_finding
  • #8 loop_group_schedule_function
  • #9 schedule_group
    at gstoptimalscheduler.c line 779
  • #10 gst_opt_scheduler_schedule_run_queue
  • #11 schedule_chain
    at gstoptimalscheduler.c line 851
  • #12 gst_opt_scheduler_iterate
  • #13 gst_scheduler_iterate
    at gstscheduler.c line 732
  • #14 gst_bin_iterate_func
    at gstbin.c line 902
  • #15 gst_bin_iterate
    at gstbin.c line 947
  • #16 idle_func
    at gst-launch.c line 27
  • #17 g_idle_dispatch
  • #18 g_main_dispatch
    at gmain.c line 1751
  • #19 g_main_context_dispatch
    at gmain.c line 2299
  • #20 g_main_context_iterate
  • #21 g_main_loop_run
    at gmain.c line 2600
  • #22 gst_main
    at gst.c line 687
  • #23 main
    at gst-launch.c line 263

I can then connect with gdb, but dont know what to do, please tell
me:-)
Comment 1 Michiel Sikkes 2003-09-02 17:39:58 UTC
Marked as GNOMVER2.4, STACKTRACE: appears to be a unique stacktrace.
Added bugsquad keyword.
Comment 2 David Schleef 2003-09-03 04:38:52 UTC
I can't reproduce the segfault, but I get a plethora of other exciting
errors.  I'm guessing this has to do with seeking on the input stream.

(as for using gdb, don't worry about it.  gst-launch is a debugging
tool meant for developers, and when it crashes, it's just convenient
for us to have it hang around for a while to connect a debugger to it.
 The interesting part is the stack trace, which is automatically
provided.)
Comment 3 David Schleef 2004-03-06 03:04:05 UTC
I can't reproduce this with HEAD.
Comment 4 David Schleef 2004-03-18 20:13:59 UTC
Could you try to reproduce this with 0.8.0, and if so, reopen the bug?
 Thanks.  (marking as NEEDINFO)
Comment 5 alexander.winston 2004-11-03 01:01:04 UTC
This bug has long been dead.