GNOME Bugzilla – Bug 303964
rhythmbox hangs waiting for read lock when running with a large database and with a search string present
Last modified: 2006-01-11 08:48:16 UTC
Please describe the problem: I have an installation with 13GB of mp3s imported into the rhythmbox database. Recently I noticed that the application would start, but then hang before it showed any of the mp3s on the interface. It looked like I had zero songs in it. I ran strace and saw that it was sitting at a FUTEX_WAIT statement, possibly waiting for a read lock somewhere. Running with -d it showed a similar message (mentioned a 'read lock' just before hanging). Also in the logs I noticed it mentioned the string 'Led' (as in Led Zeppelin, which was left in the Search box from the previous session). Workaround: I killed rhythmbox. Renamed rhythmdb.xml to rhythmdb.xml- to start with no songs in the database. Started rhythmbox. It started up properly. I then cleared the search box. Exited rhythmbox. Renamed rhythmdb.xml- back to rhythmdb.xml and started rhythmbox. Voila. It started properly and loaded all the songs in the database. My problem is solved. Just reporting this as potentially helpful troubleshooting info. Steps to reproduce: 1. Please see above. 2. 3. Actual results: please see above Expected results: please see above Does this happen every time? yes Other information: running ubuntu. I was initially suspicious of gamin (file modification daemon of gnome) because of the read lock thing. It might still be an issue as lsof initially showed a read lock on the media directories. However the issue wasn't resolved when i killed gam_serve.
Did deleting rhythmbox.xml and then readding all you music help? If so then it sounds like a corupted database. Rhythmbox doesn't handle corrupted databases too well at the moment - I don't suppose you can get a backtrace of where it is waiting? (unless you still have the old rhythmbox.xml file, that caused the hang, this could be hard)
James, not sure if it's the same problem, but I am also can reproduce such behaviour. It looks like threading problem related to different stat timeing. To make it reproducable, you can just add something like: int i, j; for (i=0; i<100000000; i++) j+=i + (int)uri; in function rythmbdb_execute_stat.
I can't reproduce this. From your comments on irc it looked like the rhythmdb action thread was getting stuck. Can you try finding the last message from it in the debug output (the first number on each line is the thread ID) and also attach a stack trace?
+ Trace 65115
Thread 1 (Thread -1209039168 (LWP 7234))
It seems to bee clearlooks issue, since changing the theme to Bluecurve makes things work nicely. My gtk is gtk2-2.6.10-2, Clearlooks from gnome-theme-2.10.1. I remember there was a similar bug in clearlooks in GtkProgressbar due to gdk error. Probably it's better just to test on newer gtk version and check if it's fixed.
Created attachment 57147 [details] Gzipped hang log
I think it's the same bug as 169310 and it should be fixed. Let everyone feel free to reopen this bug if problem still stays *** This bug has been marked as a duplicate of 169310 ***