debian-glibc, Wolfram agrees with my analysis and has posted a patch upstream. Ulrich has accepted the patch. From my side of this this fixes and closes the bug. It's up to the originator to test the next libc release.
c. ----- Forwarded message from Wolfram Gloger <[EMAIL PROTECTED]> ----- Envelope-to: carlos@localhost Delivery-date: Mon, 27 Jan 2003 06:09:57 -0500 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm List-Unsubscribe: <mailto:[EMAIL PROTECTED]> List-Subscribe: <mailto:[EMAIL PROTECTED]> List-Archive: <http://sources.redhat.com/ml/libc-alpha/> List-Post: <mailto:[EMAIL PROTECTED]> List-Help: <mailto:[EMAIL PROTECTED]>, <http://sources.redhat.com/ml/#faqs> From: Wolfram Gloger <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: MALLOC_CHECK_=1 produces false positives for arches defining MALLOC_ALIGNMENT > 8 > 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. You are correct. Below is a patch. Thank you. Regards, Wolfram. 2003-01-27 Wolfram Gloger <[EMAIL PROTECTED]> * malloc/hooks.c (mem2chunk_check): Check alignment of mem pointer, not of the computed chunk. Bug report from Carlos O'Donell <[EMAIL PROTECTED]>. --- hooks.c 2002/07/11 13:45:01 1.5 +++ hooks.c 2003/01/27 10:36:11 @@ -179,8 +179,8 @@ INTERNAL_SIZE_T sz, c; unsigned char magic; + if(!aligned_OK(mem)) return NULL; p = mem2chunk(mem); - if(!aligned_OK(p)) return NULL; if( (char*)p>=mp_.sbrk_base && (char*)p<(mp_.sbrk_base+main_arena.system_mem) ) { /* Must be a chunk in conventional heap memory. */ ----- End forwarded message ----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]