misc/89103: gcc segmentation fault errors -- ??memory leak?

Walter A. Roberts wroberts at securenym.net
Wed Nov 16 06:10:21 GMT 2005

>Number:         89103
>Category:       misc
>Synopsis:       gcc segmentation fault errors -- ??memory leak?
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Nov 16 06:10:18 GMT 2005
>Originator:     Walter A. Roberts
>Release:        6.0-Release
self/Detroit Medical Center
FreeBSD rugs.hopto.org 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov  3 09:36:13 UTC 2005     root at 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

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?

cd /usr/ports/databases/grass
make build

This will fail if there are a lot of dependencies to be built.
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!            

More information about the freebsd-bugs mailing list