Rhythmbox crashing when trying to play a mms radio stream

Bug #184533 reported by David
4
Affects Status Importance Assigned to Milestone
libmms
New
Undecided
Unassigned

Bug Description

When trying to listen to the stream mms://wm-live.sr.se/sr-p3-high Rhythmbox crashes.

Revision history for this message
David (david-xn--kremla-iuad) wrote :
Download full text (25.2 KiB)

Version: 0.11.3

What were you doing when the application crashed?
changed from one radio stream (which had just started) to another one (which
never even started buffering)

Distribution: Fedora release 8 (Werewolf)
Gnome Release: 2.20.2 2007-11-27 (Red Hat, Inc)
BugBuddy Version: 2.20.1

System: Linux 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:59 EST 2007 i686
X Vendor: The X.Org Foundation
X Vendor Release: 10300000
Selinux: No
Accessibility: Disabled
GTK+ Theme: Nodoka
Icon Theme: Fedora

Memory status: size: 154996736 vsize: 154996736 resident: 52449280 share:
23040000 rss: 52449280 rss_rlim: 4294967295
CPU usage: start_time: 1200674651 rtime: 1793 utime: 1691 stime: 102 cutime:1
cstime: 2 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/rhythmbox'

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1208969440 (LWP 3080)]
[New Thread -1305314416 (LWP 3189)]
[New Thread 70019984 (LWP 3182)]
[New Thread -1260516464 (LWP 3144)]
[New Thread -1239536752 (LWP 3097)]
0x00110402 in __kernel_vsyscall ()
#0 0x00110402 in __kernel_vsyscall ()
#1 0x00a0bac3 in __poll (fds=0xa96ff4, nfds=11, timeout=98)
    at ../sysdeps/unix/sysv/linux/poll.c:87
#2 0x00730583 in g_main_context_iterate (context=0x9fa6078, block=1,
    dispatch=1, self=0x9ebf410) at gmain.c:2996
#3 0x007308f9 in IA__g_main_loop_run (loop=0xab81c40) at gmain.c:2898
#4 0x075e23ea in IA__gtk_main () at gtkmain.c:1163
#5 0x0805f98d in main (argc=) at main.c:340

Thread 5 (Thread -1239536752 (LWP 3097)):
#0 0x00110402 in __kernel_vsyscall ()
No symbol table info available.
#1 0x00ad85d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
No locals.
#2 0x0070fd82 in g_async_queue_pop_intern_unlocked (queue=0x9ffe7b8,
    try=<value optimized out>, end_time=0x0) at gasyncqueue.c:334
        retval = <value optimized out>
        __PRETTY_FUNCTION__ = "g_async_queue_pop_intern_unlocked"
#3 0x00710125 in IA__g_async_queue_pop (queue=0x9ffe7b8) at gasyncqueue.c:374
        retval = <value optimized out>
        __PRETTY_FUNCTION__ = "IA__g_async_queue_pop"
#4 0x07afc3b2 in action_thread_main (db=0x9ff7090) at rhythmdb.c:2325
        action = (RhythmDBAction *) 0xad790b
        result = <value optimized out>
        __FUNCTION__ = "action_thread_main"
        __PRETTY_FUNCTION__ = "action_thread_main"
#5 0x0075072f in g_thread_create_proxy (data=0xac04ac8) at gthread.c:635
        __PRETTY_FUNCTION__ = "g_thread_create_proxy"
#6 0x00ad450b in start_thread () from /lib/libpthread.so.0
No locals.
#7 0x00a15b2e in clone () from /lib/libc.so.6
        fstab_state = {fs_fp = 0x0, fs_buffer = 0x0, fs_mntres = {
    mnt_fsname = 0x0, mnt_dir = 0x0, mnt_type = 0x0, mnt_opts = 0x0,
    mnt_freq = 0, mnt_passno = 0}, fs_ret = {fs_spec = 0x0, fs_file = 0x0,
    fs_vfstype = 0x0, fs_mntops = 0x0, fs_type = 0x0, fs_freq = 0,
    fs_passno = 0}}
        __elf_set___libc_subfreeres_element_fstab_free__ = (
    const void *) 0xa559a0

Thread 4 (Thread -1260516464 (LWP 3144)):
#0 0x00110402 in __kernel_vsyscall ()
No symbol table info available.
#1 0x00a0bac3 in __poll (fds=0xa96ff4, n...

Revision history for this message
Per Heldal (heldal) wrote :
Download full text (12.0 KiB)

This bug is still applies to libmms 0.4-2 in jaunty, and seems to affect all applications which use libmms through gstreamer. The crash happens when trying to connect to a mms url after having listened to some other stream or local file. Totem, rhythmbox and banshee all behave the same. The player usually connects and plays fine from the mms-url if it hasn't played some other stream first. It may be gstreamer that fails to clean up some datastructs, but the actual crash happens within libmms:

Thread 1 (Thread 0xb6749a60 (LWP 8164)):
#0 0xb16ccdcd in ?? () from /usr/lib/libmms.so.0
#1 0xb16ce3bd in mms_connect () from /usr/lib/libmms.so.0

This came from an attempt to switch from listening to a local mp3 to play from mms://straumr.nrk.no/nrk_radio_ndte_p1_h

The complete backtrace from totem is:

Thread 6 (Thread 0xb2dd4b90 (LWP 8486)):
#0 0xb7f53424 in __kernel_vsyscall ()
#1 0xb7032ae7 in *__GI___poll (fds=0x8116150, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87
#2 0xb4103912 in ?? () from /usr/lib/libpulse.so.0
#3 0xb40f33c0 in pa_mainloop_poll () from /usr/lib/libpulse.so.0
#4 0xb40f4d43 in pa_mainloop_iterate () from /usr/lib/libpulse.so.0
#5 0xb40f4e14 in pa_mainloop_run () from /usr/lib/libpulse.so.0
#6 0xb41036c3 in ?? () from /usr/lib/libpulse.so.0
#7 0xb412def2 in ?? () from /usr/lib/libpulse.so.0
#8 0xb79ce4ff in start_thread (arg=0xb2dd4b90) at pthread_create.c:297
#9 0xb703d49e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 2 (Thread 0xb4971b90 (LWP 8172)):
#0 0xb7f53424 in __kernel_vsyscall ()
#1 0xb79d58f6 in nanosleep () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7226b52 in IA__g_usleep (microseconds=3029799324) at /build/buildd/glib2.0-2.20.1/glib/gtimer.c:170
#3 0xb49b556e in gst_xvimagesink_event_thread (xvimagesink=0x83f2178) at xvimagesink.c:1573
#4 0xb72247bf in g_thread_create_proxy (data=0x83f1db8) at /build/buildd/glib2.0-2.20.1/glib/gthread.c:635
#5 0xb79ce4ff in start_thread (arg=0xb4971b90) at pthread_create.c:297
#6 0xb703d49e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 1 (Thread 0xb6749a60 (LWP 8164)):
#0 0xb16ccdcd in ?? () from /usr/lib/libmms.so.0
#1 0xb16ce3bd in mms_connect () from /usr/lib/libmms.so.0
#2 0xb16d0ec1 in mmsx_connect () from /usr/lib/libmms.so.0
#3 0xb256d6f4 in ?? () from /usr/lib/gstreamer-0.10/libgstmms.so
#4 0xb7f00d24 in gst_base_src_start (basesrc=0x8168158) at gstbasesrc.c:2454
#5 0xb7f04cf7 in gst_base_src_activate_push (pad=0x8c79660, active=1) at gstbasesrc.c:2677
#6 0xb7e40edb in gst_pad_activate_push (pad=0x8c79660, active=1) at gstpad.c:897
#7 0xb7e41a15 in gst_pad_activate_default (pad=0x8c79660) at gstpad.c:570
#8 0xb7e41b12 in gst_pad_set_active (pad=0x8c79660, active=1) at gstpad.c:659
#9 0xb7e262ab in activate_pads (pad=0x8c79660, ret=0xbfb6fd58, active=0xbfb6fdb8) at gstelement.c:2511
#10 0xb7e334f7 in gst_iterator_fold (it=0x81aa628, func=0xb7e26280 <activate_pads>, ret=0xbfb6fd58, user_data=0xbfb6fdb8) at gstiterator.c:540
#11 0xb7e25d2f in iterator_activate_fold_with_resync (iter=0x81aa628, func=0xb7e26280 <activate_pads>, user_data=0xbfb6fdb8) at gstelement.c:2543
#12 0xb7e25e14 in ...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.