From owner-freebsd-ports@FreeBSD.ORG Wed Jan 23 00:56:16 2008 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E25C16A421 for ; Wed, 23 Jan 2008 00:56:16 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta05ps.mx.bigpond.com (omta05ps.mx.bigpond.com [144.140.83.195]) by mx1.freebsd.org (Postfix) with ESMTP id EE27B13C461 for ; Wed, 23 Jan 2008 00:56:15 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from oaamta02ps.mx.bigpond.com ([124.188.162.219]) by omta05ps.mx.bigpond.com with ESMTP id <20080123005614.LNHF2309.omta05ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com> for ; Wed, 23 Jan 2008 00:56:14 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by oaamta02ps.mx.bigpond.com with ESMTP id <20080123005613.MEJF10771.oaamta02ps.mx.bigpond.com@areilly.bpa.nu> for ; Wed, 23 Jan 2008 00:56:13 +0000 Received: (qmail 26087 invoked from network); 23 Jan 2008 00:55:45 -0000 Received: from localhost (HELO duncan.reilly.home) (127.0.0.1) by localhost with SMTP; 23 Jan 2008 00:55:45 -0000 Date: Wed, 23 Jan 2008 11:55:44 +1100 From: Andrew Reilly To: "Alexandre \"Sunny\" Kovalenko" Message-ID: <20080123115544.1ef4b3a9@duncan.reilly.home> In-Reply-To: <1201048914.980.5.camel@RabbitsDen> References: <20080122094405.230a0856@duncan.reilly.home> <20080122093327.GB38360@alchemy.franken.de> <20080122211014.336999b1@duncan.reilly.home> <1201048914.980.5.camel@RabbitsDen> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.5; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A010201.479690AC.0204,ss=1,fgs=0 Cc: Joseph Koshy , freebsd-stable@freebsd.org, freebsd-ports@freebsd.org, Marius Strobl Subject: Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2008 00:56:16 -0000 On Tue, 22 Jan 2008 19:41:54 -0500 "Alexandre \"Sunny\" Kovalenko" wrote: > Am I right to assume that this is *not* i386? I have 7-PRERELEASE (i386) > cvsup'ed on January 22, early morning EST, and mred built from vanilla > 372 sources (per your earlier recommendation) on January 8th. They seem > to be pretty happy with each other. If there is any information I can > provide that will help you with your quest, please, let me know. You're correct, I'm running an amd64 system, and it turns out that a bunch of the garbage collection code is different/more complicated in that case. And it contains a bug: Found it, and fixed it. Works fine in my test-build at -O0, and I'm just re-building at -O2 to make sure... --- plt-372.orig/src/mzscheme/gc2/newgc.c 2007-10-08 21:40:43.000000000 +1 000 +++ plt-372/src/mzscheme/gc2/newgc.c 2008-01-23 11:21:25.000000000 +1100 @@ -260,13 +260,13 @@ inline static struct mpage **create_page pos = (unsigned long)p >> 48; page_maps = page_mapss[pos]; if (!page_maps) { - page_maps = (struct mpage ***)malloc(sizeof(struct mpage **) * (1 << 16)); + page_maps = (struct mpage ***)calloc(1 << 16, sizeof(struct mpage **)); page_mapss[pos] = page_maps; } pos = ((unsigned long)p >> 32) & ((1 << 16) - 1); page_map = page_maps[pos]; if (!page_map) { - page_map = (struct mpage **)malloc(sizeof(struct mpage *) * (1 << USEFUL_ADDR_BITS)); + page_map = (struct mpage **)calloc(1 << USEFUL_ADDR_BITS, sizeof(struct mpage *)); page_maps[pos] = page_map; } return page_map; In essence, it was using malloc to create second-tier page maps on the fly, and assuming (incorrectly) that the memory returned would be initialized to zero. What's mildly confusing, then, is that the memory that it was getting here in the pre-Jan-5 version of the system *was* zero. Probably just luck. Let this be a lesson: I should have turned on the malloc-debug knob in the first instance. I'll feed the patches (I've also made some tweaks to ensure that it all compiles with -Werror-implicit-function-declaration, because that's usually a good source of breakage on 64-bit systems) up-stream, and see what happens. I'll add the new patches to the port PR, too. Thanks, everyone, for your patience with my red-herring reports. -- Andrew