GNOME Bugzilla – Bug 160358
app crash when editing radio category
Last modified: 2005-07-30 05:47:54 UTC
Distribution: Fedora Core release 3 (Heidelberg) Package: rhythmbox Severity: normal Version: GNOME2.8.0 unspecified Gnome-Distributor: Red Hat, Inc Synopsis: app crash when editing radio category Bugzilla-Product: rhythmbox Bugzilla-Component: iradio Bugzilla-Version: unspecified BugBuddy-GnomeVersion: 2.0 (2.8.0) Description: Description of the crash: Steps to reproduce the crash: 1. Add radio stationwith some category 2. Edit station category Expected Results: Crash How often does this happen? 100% Additional Information: Debugging Information: Backtrace was generated from '/usr/bin/rhythmbox' (no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". (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)...[Thread debugging using libthread_db enabled] [New Thread -151156512 (LWP 8122)] [New Thread 58891184 (LWP 8126)] [Thread debugging using libthread_db enabled] [New Thread -151156512 (LWP 8122)] [New Thread 58891184 (LWP 8126)] [New Thread 48401328 (LWP 8125)] [New Thread 124615600 (LWP 8124)] [New Thread 26753968 (LWP 8123)] (no debugging symbols found)...[Thread debugging using libthread_db enabled] [New Thread -151156512 (LWP 8122)] [New Thread 58891184 (LWP 8126)] (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)...(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)...0x0062e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
+ Trace 53128
Thread 5 (Thread 26753968 (LWP 8123))
Thread 4 (Thread 124615600 (LWP 8124))
Thread 3 (Thread 48401328 (LWP 8125))
Thread 2 (Thread 58891184 (LWP 8126))
------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-12-03 12:05 ------- Unknown platform unknown. Setting to default platform "Other". Unknown milestone "unknown" in product "rhythmbox". Setting to default milestone for this product, '---' The original reporter of this bug does not have an account here. Reassigning to the person who moved it here, unknown@bugzilla.gnome.org. Previous reporter was odin@hogsbro.org. Setting to default status "UNCONFIRMED". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Appears to be a unique stack trace, according to the simple-dup-finder.
Does it still happen with the latest version?
This still happens in 0.8.8, I can't reproduce it every time tough. Seems like this happens mostly when you add a new radio station to the "Unknown" category, and later to a completly new category, but I can be wrong... Starting program: /usr/bin/rhythmbox [Thread debugging using libthread_db enabled] [New Thread -1219777824 (LWP 27831)] [New Thread -1222333520 (LWP 27834)] [New Thread -1230722128 (LWP 27835)] [New Thread -1239110736 (LWP 27836)] [New Thread -1247499344 (LWP 27837)] [New Thread -1256129616 (LWP 27838)] [New Thread -1264518224 (LWP 27839)] [Thread -1264518224 (LWP 27839) exited] RhythmDB-ERROR **: file rhythmdb-property-model.c: line 547 (rhythmdb_property_model_delete_prop): assertion failed: ((ptr = g_hash_table_lookup (model->priv->reverse_map, propstr))) aborting... Program received signal SIGABRT, Aborted. [Switching to Thread -1219777824 (LWP 27831)] 0x4104183b in raise () from /lib/tls/libc.so.6 (gdb) thread apply all bt
+ Trace 62025
Thread 1 (Thread -1219777824 (LWP 27831))
seems to be a different error. James, is the last stack trace sufficient or do we need to know the unknown function names as well?
I'm fairly sure it's the same error. I saw a similar problem when I was doing work on audio cd support - rhythmdb_property_model_iter_from_string and rhythmdb_property_model_delete_prop were getting passed empty strings. I think (but I'm not sure) that the problem was caused due to different threads using rhythmdb_commit normally what happens is 1) a RhythmDbEntry is allocated 2) the properties of the entry are set 3) rhythmdb_commit() is called what could happen 1) a RhythmDbEntry is allocated 2) some of the properties of the entry are set 3) a different thread calls rhythmdb_commit() 4) the rest of the properties of the entry are set 5) rhythmdb_commit() is called This would mean that the property model gets told that some propertie aren't set (are empty strings) and later they do get set; but as rhythmdb_entry_set is used, not rhythmdb_entry_sync, the property model doesn't get notified of the change. Two solutions I can think of a) make rhythmdb_commit() only apply to changes from the thread that calls it b) make rhythmb_commit() not apply to newly created entires, and have a special rhythmdb_commit_new_entry() or something Neither of those will be trivial, so maybe someone else can think of a better solution.
I am not familiar with RB internals, but have you considered using a monitor? not sure if pthreads supports this, but we could ensure mutual exclusion for rhythmdb_commit() this way.
The issue is that the calls (entry_new, entry_set x N, commit) should be an atomic transaction that can't be committed half-way through, because otherwise things watching for new entries get give the half-constructed entries. Another possible solution that I've though of, is that we could give entries a flag indicating whether they are "fully constructed". The flag would start off, and there would be a function like rhythmdb_entry_mark_constructed() that gets called just before the code constructing the entry calls commit(). commit() will ignore any entry that does not have the flag set, so that half-constructed entries are not comitted. I can't think (off the top of my head) of any other rhythmdb usage that needs to act as an atomic transaction. An extra feature of this is that we can detect some bad usage of entry_set/sync. entry_sync (sends change notification) should never be called before the entry is "fully constructed", and I can't think of a good reason for using entry_set (no change notification) after.
These crashes should be fixed by the patch attached to but 149799, which was just committed to cvs. Please reopen if you can reproduce it with a version with the patch applied.