From owner-freebsd-current  Sun May 28 16:12:31 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP
	id F044237B8E2; Sun, 28 May 2000 16:12:19 -0700 (PDT)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id RAA34090;
	Sun, 28 May 2000 17:12:18 -0600 (MDT)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id RAA36480; Sun, 28 May 2000 17:12:05 -0600 (MDT)
Message-Id: <200005282312.RAA36480@harmony.village.org>
Subject: Re: Internal compiler error: program ld got fatal signal 10 
To: obrien@freebsd.org
Cc: freebsd-current@freebsd.org
In-reply-to: Your message of "Sun, 28 May 2000 15:41:38 MDT."
Date: Sun, 28 May 2000 17:12:05 -0600
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

David,
	looks like I found the problem.  Or at least how to trivially
recreate the problem and how to work around it for those people that
need to do so.  I've cc'd current since I've been talking there with
people about it.

I'm fairly certain that there are malloc related bugs in the new
binutils.  If I have malloc.conf pointing at AJ, then we die in ld all
the time.  If I remove that file, then we don't and things appear to
work.  That's why some people succeeded in their upgrade, and why some
fail.

I get these failures on hello world:

int main() { printf("hello world\n"); }

cc -c xxx.c
cc -o xxx xxx.o
<ld error here>

I think that this is strong evidence that there are bugs in the new
binutils that AJ is finding.  I think it may be that it incorrectly
expects memory to be zero'd when it gets it or something.

So if you have to update your system, don't have /etc/malloc.conf
pointing at AJ:

     A       All warnings (except for the warning about unknown flags being
             set), and failure to allocate memory become fatal.  The process
             will call abort(3) in these cases.

     J       Each byte of new memory allocated by malloc(), realloc() or
             reallocf() as well as all memory returned by free(), realloc() or
             reallocf() will be initialized to 0xd0.  This options also sets
             the ``R'' option.  This is intended for debugging and will impact
             performance negatively.

     R       Causes the realloc() and reallocf() functions to always reallo-
             cate memory even if the initial allocation was sufficiently
             large.  This can substantially aid in compacting memory.

Warner

P.S.  One more beer to phk for putting this functionality into malloc :-)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message