[hypermail] Bug in hashreplynumlookup()

Hi again. I found the bug I was tracking down yesterday.

I was looking at the output hypermail generated for an archive of messages from a helpdesk mailing list. I noticed that one of the messages didn't appear in the Thread view (though it did appear in the other views).

This message (call it message M for missing), with the subject "Help", was in reply to nothing. As it turns out, there was a previous, unrelated message (call it message F for first) in the archive with the same subject.

What happened was that hypermail incorrectly thought M was "maybe" in reply to F. The problem occurs in hashreplynumlookup() in struct.c. This routine attempts to find the "parent" of a message (what it's in reply to). It tries to use the message id in the In-Reply-To: header, if it exists. Otherwise:

   472      }                           /* end of matching on inreply */
   473
   474      /* No match so far.  Now try matching on the subject, removing
   475       * one instance of "re: " from the front of the subject each
   476       * time round the loop.
   477       */
   478      {
   ...
   486          do {
   487  #if DEBUG_THREAD > 1
   488              fprintf(stderr, "extra %s\n", s);
   489  #endif
   490              ep = etable[hash(s)];
   491              while (ep != NULL) {
   492                  if ((strcasecmp(s, ep->data->subject) == 0) &&
   493                      (msgnum != ep->data->msgnum)) {
   494                      match = 1;
   495                      if (ep->data->msgnum < lowest_so_far)
   496                          lowest_so_far = ep->data->msgnum;
   497                  }
   498                  ep = ep->next;
   499              }
   500              s = oneunre(s);
   501          } while (s != NULL);
   502
   503          free(saved_s);
   504
   505          if (match) {
   506              *maybereply = 1;

The oneunre() function strips off one initial occurrence of "Re:" (and "Fw:") in the subject, or returns NULL if there is no initial "Re:". So the loop is supposed to strip off successive Re:'s until there are none left.

The problem is that the check is done at the end of the do-loop. The first time through the loop (for message M), 'ep' points at message F after line 490, and then the test in 492-493 is satisfied since both messages have subject "Help". Ultimately the 'maybereply' flag in the reply struct is set to 1.

Later on, in the FASTREPLYCODE version of crossindexthread2(), the message is dropped because rp->maybereply is 1 (actually, maybereply's are dropped only if at least one other reply to a message is a definite reply).

Sorry to be so long-winded. I think the included one-line (plus whitespace) patch fixes the problem. It just adds "if (isre(s, NULL))" before the do-loop.

-David

David Eisner            | E-mail: cradle_at_eng.umd.edu |
CALCE EPSC              | Phone:  301-405-5341       |
University of Maryland  | Fax:    301-314-9269       |
-----------------------------------------------------







TEXT/PLAIN attachment: patch to struct.c