GNOME Bugzilla – Bug 120194
Crash while changing view during library population
Last modified: 2004-12-22 21:47:04 UTC
Package: rhythmbox Severity: normal Version: 0.5.0 Synopsis: Crash while changing view during library population Bugzilla-Product: rhythmbox Bugzilla-Component: General BugBuddy-GnomeVersion: 2.0 (2.2.2) Description: Description of Problem: Segfault while adding songs and changing artist/album/genre views Steps to reproduce the problem: 1. Add a music library 2. While running, open the prefs 3. Click between the various display modes, crashed after 3-4 changes Actual Results: Crash, also got it to hang indefinately on another try Expected Results: Successful addition of tracks and ability to change the view How often does this happen? Have been able to repeat consistently Additional Information: Songs being loaded via nfs There are some bag id3 tags Oggs also exist in the collection Debugging Information: Backtrace was generated from '/usr/bin/rhythmbox' (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 16384 (LWP 1580)] [New Thread 32769 (LWP 1581)] [New Thread 16386 (LWP 1582)] [New Thread 32771 (LWP 1583)] (no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... 0x407efbf0 in waitpid () from /lib/libpthread.so.0
+ Trace 39653
Thread 1 (Thread 16384 (LWP 1580))
-- Jason Cook GnuPG Fingerprint: D531 F4F4 BDBF 41D1 514D http://reinit.org F930 FD03 262E 5120 BEDD ------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-08-18 20:03 ------- Reassigning to the default owner of the component, rhythmbox-maint@bugzilla.gnome.org.
Thanks for the information, I think it is the same bug as 120125. *** This bug has been marked as a duplicate of 120125 ***
Er, gah. Wrong bug.
I tried to reproduce this bug and I was able to reproduce it each time I tried. I had two behaviours: - the application crashes, attached my backtrace. The bug seems to be caused by an invalid EggTreeModelFilter GtkTreeIter. I investigated and it seems that EggTreeModelFilter increments its internals stamps during some row deletion or addition, to invalidate the previous iters I suppose. I bet it's a multi thread problem, TreeView sorting is done while another thread add new song/row to the gtktreeview. Could it be solved by the new thread design ?
Created attachment 19822 [details] Backtrace
- the second behaviour is maybe more alarming. It's a deadlock. Looking at the backtrace I don't understand right now how a reader thread and a writer thread can deadlock but here is the backtrace.
Created attachment 19823 [details] Backtrace of the deadlock
Eventually I understood the deadlock it happens because of rb_node_get_children which hold a read lock which must be unlock by rb_node_thaw. The problem is that between those 2 calls you shouldn't not try to acquire again a read lock, because this could lead to the following scenario: - Thread 1 calls rb_node_get_children -> acquires read lock - switch to thread 4 which tries to write on the same node, it will try to acquire a write lock but he can't since Thread 1 has a read lock, so it wait on condition. - switch again to Thread 1 which tries to acquire another read lock, it will block since there is a writer waiting (they seem to have priority). So it will block here and never release the first read lock => deadlock This is what happens here in thread 1 in the function filter_changed_cb there is a call to rb_node_get_children and then a call to rb_tree_model_node_update_node this triggers many callbacks functions and one of them calls rb_node_get_nth_child. In the meantime the Thread 4 wanted to add a child. . . I don't know if there are many place where this deadlock can arise, I only noticed one other place, in the get_status_normal function rb-library.c
This is fixed in the latest arch/cvs.