GNOME Bugzilla – Bug 109498
duplicate GtkCTreeNodes in the header pane map to the same Article*
Last modified: 2006-06-18 05:10:29 UTC
I'm not able to delete any of the Subject: "[Indie] Cato Salsa Experience" articles in a.b.s.m.2000s. This is likely due to a bug in the message_identifier_delete_messages() code I checked in last week. I don't have time to check it right now, so I'm filing a bug report s.t. I'll remember to check it later. Second related bug: I get a warning, (Null) - file acache.c: line 326 (acache_remove_entry): assertion `entry->path != NULL' message whenever I try to delete the .nfo message after trying to read it (it's expired). Looks like acache is creating an entry for the message even if it's an empty message.
Update: looks like they were deleted, but an event never got fired for the header pane.
And now I can't reproduce it. Bugger.
Can't reproduce right now, and it's not a showstopper, so punting for future investigation.
Just as I said that, I found more articles that showed the behavior. It appears to happen reasonably often with expired multiparts.
It looks like the header pane is adding duplicate entries for some articles after a `get new headers' session, which is why the articles in the earlier version of this ticket appeared to not get deleted -- they'd already been deleted, so the header pane's Message-ID-to-GtkCTreeNode had no entry for the article, so the second copy didn't get removed. Adding this check to articlelist.c: @@ -1877,6 +1882,7 @@ /* update hash table */ g_static_mutex_lock (&hash_mutex); + g_assert (g_hash_table_lookup (messageid_to_node, (gpointer)article_get_message_id(article)) == NULL); g_hash_table_insert (messageid_to_node, (gpointer)article_get_message_id(article), node); g_static_mutex_unlock (&hash_mutex); Tickles this bug with an assertion failure. It looks like the larger the group, the better the chance of making it crash.
After putting some debugging code in the header pane to get more information: with the previously-mentioned assertion in, to make sure there aren't duplicate entries: group alt.binaries.sounds.mp3.dance 211 36548 7076058 7140428 alt.binaries.sounds.mp3.dance xhdr Date 7076058 [get new headers] expire articles not in range [7076058...7140424] header pane says 393 articles removed ... remove article nolock [7075627][Thg1 Post System F - Together File 06 of 17 - System F - Together.part06.rar (01/23)][<lsvla.181744$sj7.7422341@Flipper>][0x8326d70] removing node 0x8326d70 - number 7075627 Yet, there's still a node in the header pane representing this article! Could a duplicate have been created somehow without making it in the header pane? Or is it getting re-added somehow? Additional testing is needed. Right now when I select an article in the header pane, articlelist prints out the number. It should also print out the Node*, so I can see if it's the same one or not. And calls to gtk_ctree_insert_node() need to print out information on article number & node being inserted.
Looks like this is a couple of bugs working in concert. (1) If someone posts two multiparts that have identical subject headers except one has more parts than the other -- ie, someone posted two versions for high and low bandwidth users -- Pan would not distinguish between the two threads. (2) group_remove_articles() doesn't unthread the removed articles, which can cause to articles to be marked as a parent of another article -- one that was the parent before the remove, and one that is the parent after the remove. (3) task_headers adds the new articles before removing the purged ones, so that the header pane is being refreshed in one thread while articles are being removed from the group in another thread. This is bad, but the header pane's reference counting try to get through things crash-free. A short-term hack (with some other efficiency wins) is for task_headers to remove the purged headers before adding the newly fetched headers, but this needs to be revisited. ==== (1) is fixed in CVS: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan/base&command=DIFF_FRAMESET&file=article-thread.c&rev1=1.45&rev2=1.46&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/tests&command=DIFF_FRAMESET&file=test-thread.c&rev1=0&rev2=1.1&root=/cvs/gnome (2) is fixed in CVS: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan/base&command=DIFF_FRAMESET&file=group.c&rev1=1.93&rev2=1.94&root=/cvs/gnome (3) is hacked in CVS: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-headers.c&rev1=1.141&rev2=1.142&root=/cvs/gnome