GNOME Bugzilla – Bug 120283
problems with esdsink at end of song
Last modified: 2009-08-15 18:40:50 UTC
Loaded rhythmbox, added one song to the library, played it. Rhythmbox segfaulted at the end of the song. Below is a backtrace.
+ Trace 39671
Thread 5 (Thread 49156 (LWP 29936))
Another backtrace, as requested. This time, I played around with pausing/unpausing and seeking the track. It was fine until I seeked to the end of the track.
+ Trace 39672
Thread 1 (Thread 16384 (LWP 647))
What version of GStreamer are you using?
gst-launch --gst-version reports 0.6.2.1.
Something else I've just noticed: at the end of the song, a message is printed such as Xlib: unexpected async reply (sequence 0x623b)! The specific hex value changes in between different invocations.
Welcome to XInitThreads land!
Generally that means two threads accessed GDK at the same time. However I am not aware of any place we aren't locking GDK. Anyways, Dafydd - how easily can you reproduce this error? Every time? Once a day? Once a week? And Bastien - what do you mean by the XInitThreads reference? We still can't use GDK from multiple threads, can we?
This bug has reliably manifested every single time I've tried to reproduce it.
Nope, but I would advise that you launch XInitThreads if you're going to manipulate GDK from 2 different threads.
Ok Dafydd, are you using a GNU/Linux system? If so could you try launching rhythmbox like this: MALLOC_CHECK_=2 /path/to/rhythmbox Also, your two backtraces are different, which is not unusual for a race condition. What would help is to see a few more backtraces (if they're also different) so we can try to track down a pattern.
I ran rhythmbox with MALLOC_CHECK_=2 and didn't notice any difference. Attaching an extra backtrace.
Created attachment 19592 [details] Backtrace
With GStreamer 6.3 + rhythmbox CVS, I have a similar issue, but I don't always suffer end of song crashes. At the end of a song, CPU usage jumps to 100% and the progress meter stays at the end. When I switch songs, I get: (rhythmbox:25183): GStreamer-CRITICAL **: file gstscheduler.c: line 179 (gst_scheduler_pad_unlink): assertion `GST_IS_SCHEDULER (sched)' failed (rhythmbox:25183): GStreamer-CRITICAL **: file gstscheduler.c: line 179 (gst_scheduler_pad_unlink): assertion `GST_IS_SCHEDULER (sched)' failed
even here i've the same results: it hangs at the end at the end of the song played every time. it's even possible that the problem lays on gstreamer as the same happens with gst-player. how to reproduce: 1) open gst-player(-gtk) 2) add a two songs (ogg, in my case) and press play 3) seek to "near the end" (or listen to end) 4) the music will finish 5) the playng time counter still count, un the shell i see: "audio_queue: waiting for the app to restart source pad elements" the other track is still on the playlist. 6) actually the counter says "03:32 / 02:55" and still count. versions: GStreamer Core Library version 0.6.3 GST Player 0.6.0 RhythmBox 0.5.3
If this happens with gst-player too, it would be a GStreamer bug then.
the bug is assigned to rhythmbox mantainer but has product GStreamer, is it ok?
just wondering. what gstreamer output sink is everyone using? someone in #rb just got the end-of-song crash to go away by switching from esdsink to osssink....
After reading desrt's comment, I spent some time, and confirmed that my system, which was expriencing the same problem with Rhythmbox freezing at the end of the first song, was using esdsink. So I went in and setup ALSA, and shut off ESD, and switched GStreamer to use the osssink, and now Rhythmbox no longer crashes. This appears (from my point of view), and issue with ESD, or at least between ESD and GStreamer.
GStreamer and esdsink in particular have gone through a lot of changes since 0.6. It's highly likely that this bug has been fixed, and should have been closed a long time ago. However, could you attempt to reproduce it, and if you can, reopen this bug? Thanks. (marking as NEEDINFO)
Nothing heard, so moving to closed.