GNOME Bugzilla – Bug 587285
Rhythmbox mysteriously froze when I started playing a song
Last modified: 2018-05-24 14:26:59 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:
+ Trace 216245
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.
We'll need a stack trace for all threads ("thread apply all bt" in gdb) to figure this out.
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 (http://gitorious.org/djaqua) 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.
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.
Created attachment 137760 [details] Test plugin .rb-plugin file Here's the accompanying .rb-plugin file.
we have a similar report here: https://bugs.edge.launchpad.net/ubuntu/+source/rhythmbox/+bug/406587
-- 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: https://gitlab.gnome.org/GNOME/rhythmbox/issues/767.