Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 May 2004 02:17:57 +0200
From:      "Willem Jan Withagen" <wjw@withagen.nl>
To:        <freebsd-current@freebsd.org>
Subject:   Possible bug in malloc-code
Message-ID:  <074501c44449$3ab41bc0$471b3dd4@dual>

next in thread | raw e-mail | index | archive | help
I suspect that there might be a typecasting problem somewhere
in the malloc code....

The tools I'm trying to build have a memory allocator tester which 
makes my amd64/2Gb crash real hard. As in "use the reset, Luke".
It crashes on "freeing" an invalid addres which it has generated
just one call before.

snipped of the output:
        i =         10
Alloc:  n =  167772160, ADR = 0x00000000245C7000
Alloc:  n =  201326592, ADR = 0x000000002E5C7000
Alloc:  n =  234881024, ADR = 0x000000003A5C7000
Alloc:  n =  268435456, ADR = 0x00000000485C7000
Free:   n =  268435456, ADR = 0x00000000485C7000
Free:   n =  234881024, ADR = 0x000000003A5C7000
Free:   n =  201326592, ADR = 0x000000002E5C7000
Free:   n =  167772160, ADR = 0x00000000245C7000
Alloc:  n =  201326592, ADR = 0x00000000245D7000
Alloc/Free large not inverse         10
Alloc:  n =  201326592, ADR = 0x00000000305D7000
Alloc/Free large not inverse         10
Alloc:  n =  201326592, ADR = 0x000000003C5D7000
Alloc/Free large not inverse         10
        i =         11
Alloc:  n =  335544320, ADR = 0x00000000485D7000
Alloc:  n =  402653184, ADR = 0x000000005C5D7000
Alloc:  n =  469762048, ADR = 0x00000000745D7000
Alloc:  n =  536870912, ADR = 0xFFFFFFFF905D7000
Free:   n =  536870912, ADR = 0xFFFFFFFF905D7000
--------------------

The trick is that the uppermost 32bit "suddenly" turn "negative" as if by
sign-extention through the uppermost bit of the lower word.
(I've checked that this is actually the value coming out of calloc()
And:
opteron# ll /etc/malloc.conf
lrwxr-xr-x  1 root  wheel  1 May 18 23:17 /etc/malloc.conf -> J

)

If I try to write a simple program to demonstrate, I fail to reconstruct
the environment for a crash. And the tester just runs it exhaust swap. After
which it gets a proper signal. Unfortunatly this code is compiler-generated 
and not very pretty to look at. 

The bad thing is that calling free() at this point will freeze the box....
But the problem starts with the fact that free() first complains that it
gets an invalid (junk) pointer.

Where do I start looking from here???
I guess switching on MALLOC_EXTRA_SANITY would help in userspace.
But that does not help with the kernel problem IFF I could find some trouble..

--WjW



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?074501c44449$3ab41bc0$471b3dd4>