From nobody@FreeBSD.org  Wed Nov 16 06:07:07 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D39D416A41F
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 16 Nov 2005 06:07:07 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8F90943D45
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 16 Nov 2005 06:07:07 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id jAG677jl079248
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 16 Nov 2005 06:07:07 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id jAG677X7079247;
	Wed, 16 Nov 2005 06:07:07 GMT
	(envelope-from nobody)
Message-Id: <200511160607.jAG677X7079247@www.freebsd.org>
Date: Wed, 16 Nov 2005 06:07:07 GMT
From: "Walter A. Roberts" <wroberts@securenym.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: gcc segmentation fault errors -- ??memory leak?
X-Send-Pr-Version: www-2.3

>Number:         89103
>Category:       gnu
>Synopsis:       gcc segmentation fault errors -- ??memory leak?
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Nov 16 06:10:18 GMT 2005
>Closed-Date:    Fri Jun 15 11:38:30 GMT 2007
>Last-Modified:  Fri Jun 15 11:38:30 GMT 2007
>Originator:     Walter A. Roberts
>Release:        6.0-Release
>Organization:
self/Detroit Medical Center
>Environment:
FreeBSD rugs.hopto.org 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov  3 09:36:13 UTC 2005     root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC  i386

Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518

>Description:
cc fails on segmentation fault while attempting to build 
/usr/ports/databases/grass using the make build command.

Below is a snippet of the build_report file where it failed.

-------------------------------------------
cc -pipe -c -O2 -fno-strict-aliasing -pipe   -Wall -Wconversion -Wno-implicit-int -fPIC  -I/usr/ports/x11-toolkits/tk83/work/tk8.3.5/unix -I/usr/ports/x11-toolkits/tk83/work/tk8.3.5/unix/../generic  -I/usr/ports/x11-toolkits/tk83/work/tk8.3.5/unix/../bitmaps -I/usr/local/include/tcl8.3/generic -I/usr/X11R6/include  -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1      -DTCL_NO_DEPRECATED -DUSE_TCL_STUBS /usr/ports/x11-toolkits/tk83/work/tk8.3.5/unix/../generic/tkMenu.c
/usr/ports/x11-toolkits/tk83/work/tk8.3.5/unix/../generic/tkMenu.c: In function `MenuWidgetObjCmd':
/usr/ports/x11-toolkits/tk83/work/tk8.3.5/unix/../generic/tkMenu.c:1032: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1

Stop in /usr/ports/x11-toolkits/tk83/work/tk8.3.5/unix.
*** Error code 1

Stop in /usr/ports/x11-toolkits/tk83.
*** Error code 1

Stop in /usr/ports/databases/grass.
-------------------------------------------------------------------

I was able to continue on to the next port build failure (a real problem with the port that I haven't had time to look at)  by building the dependency seperately, then restarting the /usr/ports/databases/grass build from the beginning.

This problem has been reported by several others related to a make buildworld and other package installs.  The problem is reproducible, but it does not appear to  be identically reproducible.  On review of the responses to other similar bug reports, particularly those concerning the buildilng of ports, it has been suggested that this problem may be due to a *hardware* problem.  I beg to differ.

I am running an AMD K6-233 not overclocked at sea level with very adequate cooling on a Socket 7 board, with cpu heat sensors.  Disk is a Seagate 160Gb on a plug in IDE controller (to get around the AMD bios issue with very large disks), a Maxtor 110 Mb disk and a couple of CDRs,

I do not beleive this to be a hardware problem, as this system was running  fine at high altitude (7600 feet MSL).  The problem recurs similarly with     
release 5.3-Release.  

Thinking there was a problem with 5.3-Release, I did upgrade the system to 6.0-Release with nearly identical results.  What is interesting is I ran KDE's memory watcher while the system was running and noted that memory application physical memory use climbed during the compilation process until the segmentation error occured.  

If there is a memory leak of some kind, a nearly but not quite identical error will occur in the same general way as the system runs out of memory, depending on what else happens to be demanding memory at that time.  I don't know how reliable the KDE memory info center is, or what other live tools are available (sorry guys, I'm a VMS internals guy from the dark ages), but I suspect this is what is happening.  If it were hardware related, then other heavy workload operations should cause the same issues.   They don't.  I use my system for monte carlo particle transport simulations (ie high energy physics calculations) which runs the processor and the memory ragged for hours at a time.

This precise problem has also occured while trying to build imlib3d which is not a FreeBSD port.  

Would it be advisable to upgrade to GCC 4.0.2?




>How-To-Repeat:
cd /usr/ports/databases/grass
make build

This will fail if there are a lot of dependencies to be built.
>Fix:
The port was in the process of installing dependency tk38 when it failed.

I manually went to the /usr/ports/databases/tk83

and did a make build
make install

and then returned to ../grass and ran
make build.  

(The port failed further down the line, and this is a port problem that I'll work on when I don't have to get up long before the sunshine, and let the port powers that be know what I did to fix it.)

Thanks for your help!            
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: kris 
State-Changed-When: Wed Nov 16 22:03:09 GMT 2005 
State-Changed-Why:  
Your observations on memory use are not likely to be relevant unless 
your system is running completely out of swap (in which case, that's 
your problem).  You are just observing the compiler doing its job by 
allocating memory when compiling a file. 

Whether or not you believe it, this is almost certainly due to a 
hardware failure.  Rule that out in the usual way (swap out RAM, check 
CPU cooling, cabling, power supply, etc), and then let us know whether 
it persists. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=89103 

From: "Walter Roberts" <wroberts@securenym.net>
To: <bug-followup@FreeBSD.org>, <wroberts@securenym.net>
Cc:  
Subject: Re: misc/89103: gcc segmentation fault errors 
Date: Fri, 18 Nov 2005 00:55:21 -0500

 This is a multi-part message in MIME format.
 
 ------=_NextPart_000_0007_01C5EBDA.C0C39C10
 Content-Type: text/plain;
 	charset="iso-8859-1"
 Content-Transfer-Encoding: quoted-printable
 
 Ruled out hardware issue:
 
 1.  Ran memtest 86 -- 7 full cycles (18 hours +/-).
 2.  Reduced memory from 512Mb to 256Mb, repeated with different memory chip.
 3.  Ran full burncpu, passed.
 
 Power supplies operating at nominal voltages.
 
 System is apparently not using swap space for this process.
 
 Replaced AMD K6  200 with old K6 slow processor
 
 Same failure.  CPU temps are <33C in all cases.  I don't know the exact
 numbers, but it's typically around 28C.
 
 This simply does not smell like a hardware problem, and I've been around
 these beasts for a long time....the first machine I programmed used
 magnetic CORE memory and had a whopping 8K memory with 12 bit words in
 it.   When  I ran high energy physics codes on Intel processors quite a
 few years ago, I got inconsistant answers using the same code (all
 fortran) between the i386(Intel) /unix and other machines (DEC, Cray,
 Tandem and i386(AMD)), and finally said that was hardware but couldn't
 get INTEL to believe me until after several others of us discussed the
 issue, all running the same code, and INTEL finally admitted that their
 chips couldn't add (and quickly reported to the world that it only
 affected certain 'scientific' uses which most people don't use, so they
 were safe for balancing your checkbook).    I'm willing to believe you,
 but I'd like to know why you're so convinced this is a hardware issue.
 
 The factors pointing against a hardware issue are:  1.  The machine runs
 everything else without a problem.  2.  The machine ran non-stop
 (non-reboot) on a UPS for over a half a year without a glitch, (take
 that NT), and it seems to run f90 ok, and most cc's ok.  3.  The system
 runs very compute/memory intenstive monte carlo high energy physics code
 that stores lots and lots of numbers to be written to files at the end
 of the day and works consistantly.  I would expect that if it weren't
 working properly, something would be amiss elsewhere and would expect a
 panic at some point, or the system to just plain stop working.  4.  From
 the archives it appears that more than one of us is havng a similar
 problem.  5.  This exact system ran for years without a glitch running
 FreeBSD 2.2 and FreeBSD 3.2.
 
 Is it safe to upgrade to GCC 4?  Would that solve the problem?  I'd be
 happy to get it from gnu and try it, if it won't break anything.  I
 don't have the time I used to have to go messing in operating system
 innards, much as I'd like to.
 
 It is certainly possible that a pointer is misprogrammed (or perhaps the
 fixed point  register in the AMD chip doesn't work right??) and picks up
 something funny that causes the compiler to have the "segementation
 fault  11"  That fault is consistent!
 
 Thanks
State-Changed-From-To: analyzed->feedback 
State-Changed-By: gavin 
State-Changed-When: Wed Jun 13 11:26:20 UTC 2007 
State-Changed-Why:  

To submitter:  Is this still a problem for you on newer versions of 
FreeBSD? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=89103 
State-Changed-From-To: feedback->closed 
State-Changed-By: linimon 
State-Changed-When: Fri Jun 15 11:38:11 UTC 2007 
State-Changed-Why:  
Submitter has replied that this has been fixed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=89103 
>Unformatted:
