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

Re: Segmentation fault



Hello,


> > what says 'p tmp' and 'p cur'?

> I think that tmp was 0 and cur should be 0x815be78 (it shouldn't
> have changed since the call to find_subject()), but I forgot to
> check those values the last time I got a SEGV.

Doublecheck to be sure. I saw such things happen more than once.

> The SEGV is produced on the "!tmp->fake_thread" conditional but
> I also tried to add "tmp && ..." before the "tmp != cur" on
> thread.c:432 and then craches with tmp value 0x20 (it's always
> the same).

I see.

> I get a new SEGV once o twice a day, so I'll send you the actual
> values then. Would you like me to add the "tmp && ... " on the
> thread.c:432 conditional and recompile?

No, this doesn't seem to help. But running valgrind on it could track it
down (this only works on x86 systems):

valgrind --tool=memcheck --run-libc-freeres=no --num-callers=10 
--show-reachable=yes --leak-check=yes --error-limit=no --log-file=/tmp/valgrind 
/path/to/mutt

Afther this it might be possible, that mutt *doesn't* crash any longer.
However valgrind will account the problem in /tmp/valgrind.pid or so. I
think you can also look at the logfile to see if it alreay triggered an
error. It is very verbose and there are a few false positives in.
However running mutt a day in valgrind should reveal it. Oh and valgrind
slows down the operation of mutt because it is kind of a virtual
machine.

You also could keep a core file around for future reference:

In gdb:
generate-core-file

To resume debugging later on from the command prompt:
gdb /path/to/mutt /path/to/core

> Yes, I just recompiled from CVS HEAD this week.

I see.

        Thomas