<<< Date Index >>>     <<< Thread Index >>>

Re: Threading bug due to a duplicated reference



On Sat, Mar 19, 2005 at 02:28:14PM +0100, Vincent Lefevre wrote:
> In the attached mailbox, Mutt doesn't thread the two messages together.
> I've tested against the CVS version.
> 
> The 07 Mar 2005 message contains:
> 
> Message-ID: <422C63ED.8020200@xxxxxxx>
> 
> The 16 Mar 2005 message contains:
> 
> References: <422C63ED.8020200@xxxxxxx> <422CF970.4060002@xxxxxx> 
> <422CFA56.1040203@xxxxxx> <422CFA56.1040203@xxxxxx> 
> <422CFBA7.8080001@xxxxxxxxxxx> <9SjygSk1w-B@xxxxxxxxxxxxxxxxx>
> In-Reply-To: <9SjygSk1w-B@xxxxxxxxxxxxxxxxx>
> 
> The problem seems to occur because of the duplicated reference
> <422CFA56.1040203@xxxxxx>.

I guess that Mutt thinks of the duplicated IDs as a thread loop,
here in thread.c:
|       if (is_descendant (new, thread)) /* no loops! */
|         break;

So we have to remove duplicated IDs somewhere before the
loop-detection.

I made a patch to do it while parsing headers.
Give it a try.

-- 
tamo
--- parse.c.BAK 2005-03-20 15:00:24.000000000 +0900
+++ parse.c     2005-03-20 16:07:40.000000000 +0900
@@ -141,6 +141,30 @@
        FREE (&new);
       else
       {
+       /* If NEW is already in LST, remove the old one.
+        * Because we need only the most recent message-id
+        * for making thread trees. Two identical message-id's
+        * in an env->references could break threads.
+        *                      - Reported by Vincent, 2005.
+        */
+       LIST *l = lst, *prev = NULL;
+       while (l)
+       {
+         if (!strcmp (l->data, new))
+         {
+           LIST *tmp = l;
+           if (prev)
+             l = prev->next = l->next;
+           else
+             l = lst = lst->next;
+           FREE (&tmp->data);
+           FREE (&tmp);
+         }
+         else
+           prev = l, l = l->next;
+       }
+
+       /* Now LST is ready for merging */
        t = (LIST *) safe_malloc (sizeof (LIST));
        t->data = new;
        t->next = lst;