[Openswan dev] LEAK_DETECTIVE crashers
D. Hugh Redelmeier
hugh at mimosa.com
Tue Oct 19 23:56:03 EDT 2010
| From: Paul Wouters <paul at xelerance.com>
I don't really trust gdb's source-level printouts when -O is used.
What that really means is that I don't know when it is correct and
when it is not. Worse: neither does it.
So if -O is used, and I'm desperate, I look at the assembly code to
see what is going on. It is a bit labour-instensive for me since I've
coded very little i386 and x86-64 assembly code.
| I'm seeing a few crashers with LEAK_DETECTIVE. The core files are not that
| 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);
This is in function leak_pfree. If that passert fails, it means that
p is not a pointer to an object allocated by a leak-detective
allocator or that some code has scribbled over fields that it should
Are you running with Electric Fence?
| 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
Do you really think that p is -1 or do you think that GDB is picking
up the wrong object when trying to find the value of p?
The first (wrong) guess is to look at the assignment to p
p = ((union mhdr *)ptr) - 1;
and say: oh, ptr was NULL, so p == -1. But this is wrong because that
subtraction is really of -1 * sizeof(union mhdr). That's roughly -40.
My best guess is that the value printed for p is bogus (due to -O
Could you print the value of ptr? It is more likely correct.
More information about the Dev