[Openswan dev] LEAK_DETECTIVE crashers
david_mccullough at mcafee.com
Tue Oct 19 23:55:19 EDT 2010
Jivin Paul Wouters lays it down ...
> 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);
> #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 ?
David McCullough, david_mccullough at mcafee.com, Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
More information about the Dev