This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
MALLOC_CHECK_=1 produces false positives for arches defining MALLOC_ALIGNMENT > 8
- From: Carlos O'Donell <carlos at baldric dot uwo dot ca>
- To: libc-alpha at sources dot redhat dot com
- Date: Tue, 21 Jan 2003 00:30:51 -0500
- Subject: MALLOC_CHECK_=1 produces false positives for arches defining MALLOC_ALIGNMENT > 8
libc-alpha,
I noticed that for arches defining MALLOC_ALIGNMENT > 8, which is a
valid thing according to glibc/malloc/malloc.c, that the checks in
hooks.c, particularly those in mem2chunk_check(), seemed a bit erroneous.
glibc/malloc/hooks.c:
165 p = mem2chunk(mem);
166 if(!aligned_OK(p)) return NULL;
glibc/malloc/malloc.c:
346 #ifndef INTERNAL_SIZE_T
347 #define INTERNAL_SIZE_T size_t
348 #endif
349
350 /* The corresponding word size */
351 #define SIZE_SZ (sizeof(INTERNAL_SIZE_T))
...
368 #define MALLOC_ALIGN_MASK (MALLOC_ALIGNMENT - 1)
...
1762 #define mem2chunk(mem) ((mchunkptr)((char*)(mem) - 2*SIZE_SZ))
...
1774 #define aligned_OK(m) (((unsigned long)((m)) & (MALLOC_ALIGN_MASK)) == 0)
So for MALLOC_ALIGNMENT of >8, when the aligned memory is converted back
to a chunk my subtracting "2*SIZE_SZ" or "2*size_t" you may not get
back a chunck that observes MALLOC_ALIGNMENT and the check on line 166
of hooks.c is not true.
HPPA defines MALLOC_ALIGNMENT as 16 and seems to exhibit false positives
when testing code with MALLOC_CHECK_. The memory in the chunk is aligned
to 16, but the chunk pointer, after subtracting 8, is obviously not.
The code in hooks.c looks like it needs some love :)
c.