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)