On Sun, Feb 2, 2014 at 3:26 PM, walt <w41...@gmail.com> 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. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
