Re: [Pan-users] Segfaults from recent pan2.git

[Zan Lynx]

On Sun, Feb 2, 2014 at 3:26 PM, walt <address@hidden> wrote:
> Starting program: /home/wa1ter/bin/pan.35b
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> [New Thread 0x7fffedbdb700 (LWP 21951)]
> [New Thread 0x7fffed3da700 (LWP 21952)]
> [New Thread 0x7fffecbd9700 (LWP 21953)]
> [New Thread 0x7fffe7fff700 (LWP 21954)]
> [New Thread 0x7fffe4c98700 (LWP 21957)]
> *** Error in `/home/wa1ter/bin/pan.35b': corrupted double-linked list: 
> 0x0000000017d84e70 ***
>
> That was all there was -- no backtrace was available.


This kind of error is almost certainly caused by memory corruption.
Which means that the actual problem happened almost anywhere other
than here where it crashed. :-)

If the stack trace doesn't work in gdb that is a clue that would lead
me to believe some part of the program wrote over the stack. Which is
where the stack trace would have been. :-) I would look for a pointer
(or smart pointer) allocated on the stack as a local function
variable, that is positioned next to some kind of buffer or array.
That array probably got overwritten and when the pointer got delete()
called on it, it corrupted the heap. Just a guess.

I find valgrind is the best tool to solve these. The problem is that
valgrind makes the program run much more slowly. Give valgrind a try
if electric fence doesn't work for you.