Date: Wed, 23 Jan 2008 11:55:44 +1100 From: Andrew Reilly <andrew@areilly.bpc-users.org> To: "Alexandre \"Sunny\" Kovalenko" <gaijin.k@gmail.com> Cc: Joseph Koshy <jkoshy@freebsd.org>, freebsd-stable@freebsd.org, obrien@freebsd.org, freebsd-ports@freebsd.org, Marius Strobl <marius@alchemy.franken.de> Subject: Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Jan 2008 19:41:54 -0500
"Alexandre \"Sunny\" Kovalenko" <gaijin.k@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080123115544.1ef4b3a9>