[Openswan dev] LEAK_DETECTIVE crashers

[D. Hugh Redelmeier]

| 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
| 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);

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
not have.

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
confusing GDB).

Could you print the value of ptr?  It is more likely correct.