Re: Segmentation fault
On Friday, 13 May 2005 at 12:17, Thomas Glanzmann wrote:
> > ==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?
Looks like that's been broken for the last five years, and should be
fixed.
> 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.
Nice job tracking it down. You've convinced me I should check out
valgrind one of these days :)
> @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.
I've never gotten comfortable with the threading code, so I don't have
a great deal of confidence that the patch you sent continues to thread
correctly. But it's a big improvement over segfaulting. I'll try to
run a few sanity checks against it this weekend and commit it if
nothing turns up. I'm sorry I don't have more time now to take a
really good look. If it does work, I owe you a beer. That's one of the
worst bugs in mutt.