GNOME Bugzilla – Bug 112280
Deleting message hangs balsa
Last modified: 2004-12-22 21:47:04 UTC
Balsa 2.0.10 and latest CVS version tested. I'm using balsa, with my mailboxes on a remote IMAP server. Preferences -> Misc settings that might be relevant: [ ] debug [ ] empty trash on exit [ ] Delete immidiately [v] Hide deleted messages Threading for this folder is set to 'jwz threading', however, setting it to 'simple threading' doesn't make a difference. If I collapse a thread with 2 messages in it in the message list window, then select that thread/message by clicking on it, and then press 'd' (for delete message) balsa hangs completely. Clicking 'thrash/delete' has the same effect. Deleting the individual messages seperately when the thread is expanded works normally. This is 100% reproducible, also on local mailboxes. Also, when a new message arrives as a reply to a message already in the mailbox, that message is collapsed. Expanding that thread and then selecting+deleting the first message results in the same hang. Esp. the last thing happens enough to make balsa unuseable. Console output just before the hang: Opening 4 mailboxes on startup. Adding child Re: test..... Moving Re: test..... to top level Stack trace:
+ Trace 36561
This is a similar stack trace to the one in #107715.
Balsa just froze up when I wasn't doing anything; it was on another desktop, and when I switched to that desktop I saw that balsa was frozen again. Stack trace below. I'll try to see if I can dig up another GTK lib. The one I'm using currently is gtk+2.0_2.2.1-4 from Debian. (gdb) where
+ Trace 36563
Okay, I got the latest gtk+ from CVS (the gtk-2-2 branch) today, built it, and ran balsa against it. It doesn't help. The bug is still there. However, if I build balsa itself with --disable-threads, then the bug doesn't appear. So it is threads-related. Now reading the source, and the stack trace, I see that mailbox_messages_changed_status_idle in balsa-index.c calls gdk_threads_enter(), and finally gtk_tree_view_expand_all() in the gdb library ends up calling GDK_THREADS_ENTER() as well -> deadlock. But whose fault it is?
Well, that would seem to be a recipe for threadlock...but the version of gtk_tree_view_expand_all that I'm seeing in cvs is like this: /** * gtk_tree_view_expand_all: * @tree_view: A #GtkTreeView. * * Recursively expands all nodes in the @tree_view. **/ void gtk_tree_view_expand_all (GtkTreeView *tree_view) { g_return_if_fail (GTK_IS_TREE_VIEW (tree_view)); if (tree_view->priv->tree == NULL) return; _gtk_rbtree_traverse (tree_view->priv->tree, tree_view->priv->tree->root, G_PRE_ORDER, gtk_tree_view_expand_all_helper, tree_view); } and I don't see a call to GDK_THREADS_ENTER()--is this not the code that you have? I'm guessing that it's the cast check GTK_IS_TREE_VIEW() that's causing the lock, because that also tries to grab one, but it's in the GType system, not the gdk lock.
FWIW, G_TYPE_CHECK_INSTANCE_TYPE from glib2-2.2.1-1 does not touch gtk thread lock. Also, I could not find gtk_threads_lock in entire gtktreeview.c in gtk-2-2 branch at all. I think more information is needed here.
That's correct, there is no gtk_threads_lock in gtktreeview.c, but there's a lot of GDK_THREADS_ENTER() calls. I think somewhere gdb got confused and listed the wrong stacktrace. No idea why, perhaps the threading code got confused. Anyway, I tried the patch against gtk+ that was mentioned in http://bugzilla.gnome.org/show_bug.cgi?id=111286 and the bug appears to be fixed with that patch applied against gtk. So I guess I could try to get a better stack trace by backing out that patch and trying again, but as the problem seems to have been identified and solved already, it's probably a better idea to merge this bug with 111286 and close it when a new gtk gets released. Thanks! Mike.
*** Bug 114066 has been marked as a duplicate of this bug. ***
*** Bug 107715 has been marked as a duplicate of this bug. ***
Old and probably Gtk+ related