[Openswan dev] LEAK_DETECTIVE crashers

[David McCullough]

Jivin Paul Wouters lays it down ...
> 
> Hi,
> 
> I'm seeing a few crashers with LEAK_DETECTIVE. The core files are not that useful,
> as a lot of symbols are optimised out. These crashes seem to happen at the
> following code:
> 
>     at /usr/src/debug/openswan-2.6.30rc1/lib/libopenswan/alloc.c:138
> 138			passert(p->i.older->i.newer == p);
> 
> But in different call traces. This one shows:
> 
> (gdb) p p
> $7 = (union mhdr *) 0xffffffffffffffff
> (gdb) p p->i.older->i.newer
> Cannot access memory at address 0x7
> 
> The code is reached via pfree()
> Of the two traces I have, the pfree()'s involved are:
> 
> #5  0x00002aefefc1afe0 in calc_ke (r=<value optimized out>)
>      at /usr/src/debug/openswan-2.6.30rc1/programs/pluto/crypt_ke.c:179
> 179	    freeanychunk(prime);
> 
> and:
> 
> #5  0x00002b7b8c97c7b8 in fetch_asn1_blob (arg=<value optimized out>)
>      at /usr/src/debug/openswan-2.6.30rc1/programs/pluto/fetch.c:332
> 332	        pfree(uri);
> (gdb) p uri
> No symbol "uri" in current context.
> 
> This second one does not even allow me to print uri in gdb:
> 
> I will try to get binaries without optimization, but I was hoping Hugh might have
> some hints on where to look at for these. They seem not t obe double frees.


What kind of config is needed to provoke these,  or just enabling
LEAK_DETECTIVE on ordinary tunnels is enough ?

Cheers,
Davidm

-- 
David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org