GNOME Bugzilla – Bug 154108
Crash on startup with new read-only code
Last modified: 2005-06-12 18:11:12 UTC
Crashes on a good song: [0x8f058d8] [rhythmdb_process_events] rhythmdb.c:1250 (22:34:53): processing RHYTHMDB_EVENT_STAT [0x8f058d8] [rhythmdb_process_stat_event] rhythmdb.c:1127 (22:34:53): not modified: file:///home/data/Music/Albums/Franz%20Ferdinand%20-%20Franz%20Ferdinand/01.%20Franz%20Ferdinand%20-%20Jacqueline.mp3 RhythmDB-ERROR **: file rhythmdb.c: line 1715 (rhythmdb_entry_set): assertion failed: (rhythmdb_get_readonly (db) == FALSE) aborting... Here's the bt:
+ Trace 50605
It's trying to change the mount-point property during the initial load, and actually crashing in the "rhythmdb_get_readonly (db) == FALSE" assert (not later as gdb says).
Still occurs with current CVS HEAD, it's trying to update the "last seen" entry this time:
+ Trace 60677
More interesting is what the second thread is doing:
+ Trace 60678
From the original crashing thread: (gdb) frame 6
+ Trace 60680
$1 = (RhythmDBEntry *) 0x860e620 (gdb) p entry->location $2 = 0x860f8a8 "file:///home/hadess/Desktop/data/Music/Albums/Gorillaz%20-%20G%20Sides/02.%20Gorillaz%20-%20Dracula.mp3" We're not even processing the same file. I've pushed a small fix that might do something: * rhythmdb/rhythmdb.c: (rhythmdb_save_thread_main): send a RHYTHMDB_EVENT_DB_SAVED event even if we don't have to save the database, otherwise the read counter doesn't get decreased
I think there's a fix in my playbin branch which I haven't pushed anywhere else, I'll have to check that.
Created attachment 47414 [details] [review] Patch from my playbin branch
What this patch does is to make sure that the database is always modified from the main thread, and it also makes sure the database isn't read-only before modifying it. It queues database changes to be able to process them later if the database is read-only. This patch fixes the startup crashes as far as I could see, however I have seen a few big slowdowns at startup with it applied but I didn't really dig further to try to figure out what was going on (from the console trace, it seemed lots of stuff was being queued to be processed later, but I dunno why it happened nor why it slowed things down).
2005-06-12 Christophe Fergeau <teuf@gnome.org> * lib/rb-util.c: (rb_is_main_thread), (rb_threads_init): * lib/rb-util.h: * rhythmdb/rhythmdb.c: (rhythmdb_event_free), (rhythmdb_shutdown), (rhythmdb_read_enter), (rhythmdb_read_leave), (timeout_rhythmdb_commit), (set_metadata_string_default_unknown), (set_props_from_metadata), (rhythmdb_process_stat_event), (rhythmdb_process_metadata_load), (rhythmdb_process_queued_entry_set_event), (rhythmdb_process_events), (action_thread_main), (rhythmdb_entry_sync), (rhythmdb_entry_set_internal), (rhythmdb_entry_queue_set), (rhythmdb_entry_set), (rhythmdb_prop_get_type), (entry_volume_mounted_or_unmounted), (rhythmdb_entry_set_mount_point), (rhythmdb_entry_set_visibility): * rhythmdb/rhythmdb.h: * shell/main.c: (main): * sources/rb-source.c: (rb_source_update_play_statistics): * widgets/rb-entry-view.c: (rb_entry_view_rated_cb): reimplement rhythmdb_entry_queue_set, this should fix some crashes when doing a rhythmdb_entry_set while the db is read-only