This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]