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 587285 - Rhythmbox mysteriously froze when I started playing a song
Rhythmbox mysteriously froze when I started playing a song
Product: rhythmbox
Classification: Other
Component: general
Other All
: Normal critical
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Reported: 2009-06-29 09:47 UTC by Richard Schwarting
Modified: 2018-05-24 14:26 UTC
See Also:
GNOME target: ---
GNOME version: ---

Stacktrace of threads when Rhythmbox seizes up (16.07 KB, text/plain)
2009-07-01 06:03 UTC, Richard Schwarting
Test plugin (1.47 KB, text/plain)
2009-07-03 04:25 UTC, Richard Schwarting
Test plugin .rb-plugin file (268 bytes, text/plain)
2009-07-03 04:27 UTC, Richard Schwarting

Description Richard Schwarting 2009-06-29 09:47:46 UTC
Steps to reproduce:
1. start Rhythmbox
2. play music
3. try to adjust volume when I realise it's low
4. nothing, it is frozen

Stack trace:

  • #0 __kernel_vsyscall
  • #1 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S line 142
  • #2 _L_lock_752
    from /lib/
  • #3 __pthread_mutex_lock
    at pthread_mutex_lock.c line 61
  • #4 IA__g_static_rec_mutex_lock
    at gthread.c line 313
  • #5 _threads_enter
    at rb-util.c line 355
  • #6 gdk_event_check
    at gdkevents-x11.c line 2338
  • #7 IA__g_main_context_check
    at gmain.c line 2323
  • #8 g_main_context_iterate
    at gmain.c line 2442
  • #9 IA__g_main_loop_run
    at gmain.c line 2653
  • #10 IA__gtk_main
    at gtkmain.c line 1205
  • #11 main
    at main.c line 333

Other information:
This could be related to a Python plugin I run at start which adjusts volume.  I've had complications with it before for reasons I can't believe.
Comment 1 Jonathan Matthew 2009-06-29 23:07:32 UTC
We'll need a stack trace for all threads ("thread apply all bt" in gdb) to figure this out.
Comment 2 Richard Schwarting 2009-07-01 06:03:37 UTC
Created attachment 137670 [details]
Stacktrace of threads when Rhythmbox seizes up

It actually seems to freeze up without much encouragement.  

I'm not sure if there's much to be done.  It only happens when I have a plugin I wrote myself active.  This caused it to occasionally freeze in Fedora 10 and sometimes worked in Fedora 11, but no longer. 

The plugin ( is written in Python and intends on announcing, via Speech Dispatcher's Python API, a track's artist and title before and after it plays.  Complications like freezing arose when I started trying to quiet the volume while speaking.  

I'll note that Rhythmbox still seems to be running, but the GUI is totally blocked.  The current song finishes, and the plugin even still prints out to console periodically after the GUI freezes.  No other songs are cued up, though. 

I'm looking into it more this evening, anyway, to see if I can better isolate where the problem is.
Comment 3 Richard Schwarting 2009-07-03 04:25:42 UTC
Created attachment 137759 [details]
Test plugin

I've stripped down the plugin code to what seems to be the bare minimum.  

The test case might require a working installation of Speech Dispatcher (which I hear is possibly going to replace gnome-speech for GNOME 3.0 due to gnome-speech's bonobo usage and KillBonobo) and its Python API.  

Rhythmbox's UI seems to freeze as a result of interaction with Speech Dispatcher when it uses callbacks to alter volume.  

What the test case does
When the playing-song-changed signal is caught, 
* calls speechd's speak command to read a string aloud, and
* creates a few callbacks, 
** one to lower the volume when the speech begins (so it can be heard over music)
** one to raise/restore the volume when the speech ends

(due to bug 494298, the BEGIN call back isn't always called, which I think it needs to be to reproduce the bug, but I'm not sure; in this case, just press next a few times and perhaps try to adjust the volume yourself until freezing)
Rhythmbox only freezes when using Speech Dispatcher's callbacks to alter volume for me.  If I alter volume directly without using the callbacks, there is no issue.  Like, call lower_volume() before speaking and using glib.add_timeout() to restore it after some N seconds, it doesn't happen.  Or if I just litter the code with many raises and lowers, it doesn't bother Rhythmbox.  Only when being called from within Speech Dispatcher's callbacks.

Sometimes when I tested this, X would seem to lock up.  I could still ctrl-alt-F2 to a terminal and killall -9 rhythmbox, which would unlock X.


While it seems to be caused by interaction with Speech Dispatcher, which has a few races itself, I sort of think Rhythmbox's UI shouldn't be freezing due to silliness in a plugin.  I can keep digging around and try to find out more specifics, if that would help.
Comment 4 Richard Schwarting 2009-07-03 04:27:26 UTC
Created attachment 137760 [details]
Test plugin .rb-plugin file

Here's the accompanying .rb-plugin file.
Comment 5 Pedro Villavicencio 2009-08-06 13:53:00 UTC
we have a similar report here:

Comment 6 GNOME Infrastructure Team 2018-05-24 14:26:59 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: