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

Re: Segmentation fault



Hello Alex,

> I'm attaching two valgrind logs with mutt_sort_threads references
> involved in memory leaks (I'm not an expert on valgrind but it
> seems that it could be a bug in *alloc() libc routines).

mutt is full of memory leaks but they leak most of the time only a few
bytes so .... forget it. :-)

But the real interesting stuff comes here:

> ==30662== Source and destination overlap in strncpy(0x52BFCF10, 0x52BFCF19, 
> 128)
> ==30662==    at 0x1B9019B6: strncpy (mac_replace_strmem.c:113)
> ==30662==    by 0x80D7FD1: imap_parse_path (util.c:141)
> ==30662==    by 0x80D7CD9: imap_expand_path (util.c:57)
> ==30662==    by 0x80BAB66: _mutt_expand_path (muttlib.c:482)
> ==30662==    by 0x80BA4C9: mutt_expand_path (muttlib.c:326)
> ==30662==    by 0x80544D8: mutt_parse_mailboxes (buffy.c:197)
> ==30662==    by 0x807329F: mutt_parse_rc_line (init.c:1725)
> ==30662==    by 0x8072F43: source_rc (init.c:1636)
> ==30662==    by 0x807316D: parse_source (init.c:1686)
> ==30662==    by 0x807329F: mutt_parse_rc_line (init.c:1725)

This is at least bad coding style and maybe a bug. Breandan, could you
double check that, too, please?

> ==30662== Invalid read of size 1
> ==30662==    at 0x1B901A63: strcmp (mac_replace_strmem.c:250)
> ==30662==    by 0x80B9870: mutt_strcmp (lib.c:637)
> ==30662==    by 0x807A474: hash_find_hash (hash.c:108)
> ==30662==    by 0x80B6EE0: mutt_sort_threads (thread.c:786)
> ==30662==    by 0x80B4554: mutt_sort_headers (sort.c:291)
> ==30662==    by 0x80640B6: update_index (curs_main.c:317)
> ==30662==    by 0x8064711: mutt_index_menu (curs_main.c:492)
> ==30662==    by 0x8082148: main (main.c:934)
> ==30662==  Address 0x1BD5D308 is 0 bytes inside a block of size 43 free'd
> ==30662==    at 0x1B902490: free (vg_replace_malloc.c:153)
> ==30662==    by 0x80B8A9D: safe_free (lib.c:131)
> ==30662==    by 0x80BB189: mutt_free_envelope (muttlib.c:656)
> ==30662==    by 0x80D6362: imap_fetch_message (message.c:472)
> ==30662==    by 0x808E67C: mx_open_message (mx.c:1417)
> ==30662==    by 0x80616F1: mutt_copy_message (copy.c:677)
> ==30662==    by 0x8059161: mutt_display_message (commands.c:146)
> ==30662==    by 0x806666B: mutt_index_menu (curs_main.c:1144)
> ==30662==    by 0x8082148: main (main.c:934)

and here is your segfault. As you can see mutt tries to thread a message
which was freed before.  The address in question is 0x1BD5D308 which was
freed from imap_fetch_message. And the mutt_index-menu tries to thread
it later on.  So I guess the imap code does free the eMail before it
takes it out of the list.

I guess I found the problem. CTX has three hashes: id_hash, subj_hash *and*
thread_hash. But the thread_hash isn't handled at all. So it breaks of
course.

(See message.c:472 ff)

  if (ctx->id_hash && h->env->message_id)
    hash_delete (ctx->id_hash, h->env->message_id, h, NULL);
  if (ctx->subj_hash && h->env->real_subj)
    hash_delete (ctx->subj_hash, h->env->real_subj, h, NULL);
  mutt_free_envelope (&h->env);                                     <<<< THIS 
IS THE FREE
  h->env = mutt_read_rfc822_header (msg->fp, h, 0, 0);
  if (ctx->id_hash && h->env->message_id)
    hash_insert (ctx->id_hash, h->env->message_id, h, 0);
  if (ctx->subj_hash && h->env->real_subj)
    hash_insert (ctx->subj_hash, h->env->real_subj, h, 1);

@Brendan: Any ideas?

I attached a patch which at leasts compile and doesn't do any obvious
harm for me. But I think Brendan should look at it.

        Thomas
--- a/imap/message.c
+++ b/imap/message.c
@@ -469,6 +469,8 @@
     hash_delete (ctx->id_hash, h->env->message_id, h, NULL);
   if (ctx->subj_hash && h->env->real_subj)
     hash_delete (ctx->subj_hash, h->env->real_subj, h, NULL);
+  if (ctx->thread_hash && h->env->message_id)
+    hash_delete (ctx->thread_hash, h->env->message_id, h, NULL);
   mutt_free_envelope (&h->env);
   h->env = mutt_read_rfc822_header (msg->fp, h, 0, 0);
   if (ctx->id_hash && h->env->message_id)