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