[Openswan dev] LEAK_DETECTIVE hits passert()

[Paul Wouters]

On Tue, 30 Nov 2010, D. Hugh Redelmeier wrote:

> On Mon, 29 Nov 2010, Paul Wouters wrote:
>
> | I have a somewhat rare crasher that seems to only happen with LEAK_DETECTIVE.
> | I have a core and source. I was wondering if you could shed some light on this?
> |
> | Specifically, it hits the passert in the openswan alloc.c code (non Kaminski
> | related:)
> |
> | void
> | leak_pfree(void *ptr, int leak)
> | {
> |     union mhdr *p;
> |
> |     if(leak) {
> |         passert(ptr != NULL);
> |         p = ((union mhdr *)ptr) - 1;
> |         passert(p->i.magic == LEAK_MAGIC);
> |         if (p->i.older != NULL)
> |             {
> |                 passert(p->i.older->i.newer == p);
> |                 p->i.older->i.newer = p->i.newer;
> |             }
> |
> | It hits the 2nd passert here.
> |
> | Looks like there is garbage there:
> |
> | (gdb) p p
> | $4 = (union mhdr *) 0x2b1fc4a0f270
> | (gdb) p *p
> | $11 = {i = {name = 0x2b1fb79f508c "saved gi value", older = 0x2b1fc4b1dc40,
> |     newer = 0x0, magic = 3671129837, size = 256}, junk = 47415224651916}
>
> If this is correct, the second assertion should not trip:
>
> LEAK_MAGIC == 0xDAD0FEEDul == 3671129837ul
>
> So: why do you think that the second assertion is tripping?  Are you
> sure that it isn't something else?  Like perhaps the third passert?

Sorry, I missed the very first passert. Yes I meant it is triggering the third
passert()

> If you did mean "third" instead of "2nd", tell me and ignore the rest
> of what I say in this message.

> | (gdb) p p->i.older
> | $5 = (union mhdr *) 0x2b1fc4b1dc40
> | (gdb) p p->i.older->i.newer
> | $6 = (union mhdr *) 0xffffffff
> | (gdb) p p->i.older->i
> | $7 = {name = 0x2b1fb9847ba8 "\230{\204\271\037+", older = 0x2b1fc4a0fa50,
> |   newer = 0xffffffff, magic = 0, size = 0}
> | (gdb) p p->i.older->i.name
> | $8 = 0x2b1fb9847ba8 "\230{\204\271\037+"
> | (gdb)
> |
> | I am not sure how to further debug this though. I was hoping to be able to
> | have LEAK_DETECTIVE on by default, but it seems to be resulting in passert()'s
> | hitting.
>
> This looks like crap.  A pointer equal to 0xffffffff is both invalid
> (insufficiently aligned) and EXTREMELY unlikely. (You are on a
> machine with 64-bit pointers and this one is therefore
> 0x00000000ffffffff.)

Yes :)

Paul