From owner-freebsd-current@FreeBSD.ORG Mon May 31 14:23:56 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 9905116A4CE for ; Mon, 31 May 2004 14:23:56 -0700 (PDT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7215443D45 for ; Mon, 31 May 2004 14:23:55 -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 i4VLJL67077722; Mon, 31 May 2004 23:19:21 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <0c1301c44754$fc027160$471b3dd4@dual> From: "Willem Jan Withagen" To: "Poul-Henning Kamp" References: <2675.1086036694@critter.freebsd.dk> Date: Mon, 31 May 2004 23:19:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 cc: freebsd-current@freebsd.org Subject: Re: 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: Mon, 31 May 2004 21:23:56 -0000 > In message <0be501c4474f$bb115400$471b3dd4@dual>, "Willem Jan Withagen" writes: > > > > 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 > >rMemoryDrv in free(): error: junk pointer, too high to make sense > >Abort (core dumped) > > As for this part: Does the program in fact have a prototype for > malloc(3) in sight ? Can you try to explicitly add a wrong prototype > to see that it complains ? Alternatively, #include to get > it a prototype. > > I looked briefly at the source code of the test-program and while I am > in a position to say that it is doing something wrong with the casting, > it does look mightily bogus to me. Fair question, and to be honest. I assume(d) that it somewhere in its infinite load of obscurity included stdlib.h Hold on, I'll check.... Well I'm actually using calloc() since the original writer assumes that malloc returns zero-ed space. And looking through the preprocessed output stdlib.h is not included.... And bingo, we have a winner with stdlib.h manually included: Alloc/Free large not inverse 11 Alloc: n = 402653184, ADR = 0x00000000605E7000 Alloc/Free large not inverse 11 Alloc: n = 402653184, ADR = 0x00000000785E7000 Alloc/Free large not inverse 11 i = 12 Alloc: n = 671088640, ADR = 0x00000000905E7000 Alloc: n = 805306368, ADR = 0x00000000B85E7000 Alloc: n = 939524096, ADR = 0x00000000E85E7000 No more sign-extention trouble I'm afraid that these kinds of 'bugs' are going to haunt me for the remainder of porting the tool. :( Thanx, --WjW