From owner-freebsd-current@FreeBSD.ORG Thu May 27 17:22:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67AC716A4CE for ; Thu, 27 May 2004 17:22:34 -0700 (PDT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F0C343D39 for ; Thu, 27 May 2004 17:22:33 -0700 (PDT) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with SMTP id i4S0Ha67074769 for ; Fri, 28 May 2004 02:17:36 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <074501c44449$3ab41bc0$471b3dd4@dual> From: "Willem Jan Withagen" To: Date: Fri, 28 May 2004 02:17:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Possible bug in malloc-code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2004 00:22:34 -0000 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