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

[walt]

On 02/03/2014 02:33 PM, Zan Lynx wrote:
> 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.

For ten days I've been using Heinrich's own valgrind script:

$cat ~/src/pan2/pan/gui/my-valgrind.sh 
#/bin/sh
export G_SLICE=always-malloc
export G_DEBUG=gc-friendly
export GLIBCXX_FORCE_NEW=1
valgrind --tool=memcheck --leak-check=full --leak-resolution=high 
--num-callers=42 --log-file=pan-valgrind --show-reachable=yes ./pan

and I haven't produced a segfault yet :(   The code does indeed run very
slowly with valgrind, so I'm suspecting some kind of race condition that
doesn't trigger at such slow execution speeds.

I know almost nothing about valgrind or the meaning of the flags above,
so I'd welcome any suggestions about what I can do to speed things up
and possibly trigger the segfault.

Duncan:  I installed 'duma' and I'm still trying to make it through the
man page :)  I just don't know enough (yet) to understand it.  Any hints
would be most welcome.