Bug 29346

Summary:	c++ internal Error: Killed (program cc1plus)
Product:	[Retired] Red Hat Linux	Reporter:	Kyle Jacobs <kfj001>
Component:	gcc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED NOTABUG	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-02-25 23:13:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kyle Jacobs 2001-02-25 06:37:00 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.1-0.1.9 i686; en-US; 0.7)
Gecko/20010203


While compiling STLPort4 (as a dependency of Sun's latest Openoffice), an
error was received during the "make all" phase of compilation.

The output:

[kyle@localhost src]$ make all
*** ATTENTION! ***
This makefile tries to use system locale which might not work well with all
glibc flavours.
If build fails, please resort to gcc.mak which will build C-locale only
version for STLport 4.0
******************
mkdir -p obj/GCC/ReleaseD
c++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized
-D__STL_USE_GLIBC -D__STL_REAL_LOCALE_IMPLEMENTED -O2 -aseD/dll_main.o
c++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized
-D__STL_USE_GLIBC -D__STL_REAL_LOCALE_IMPLEMENTED -O2 -ReleaseD/range_errors.o
c++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized
-D__STL_USE_GLIBC -D__STL_REAL_LOCALE_IMPLEMENTED -O2 -eD/string.o
c++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized
-D__STL_USE_GLIBC -D__STL_REAL_LOCALE_IMPLEMENTED -O2 -aseD/ios_base.o
c++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized
-D__STL_USE_GLIBC -D__STL_REAL_LOCALE_IMPLEMENTED -O2 -ios.o
c++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized
-D__STL_USE_GLIBC -D__STL_REAL_LOCALE_IMPLEMENTED -O2 -easeD/streambuf.o
c++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized
-D__STL_USE_GLIBC -D__STL_REAL_LOCALE_IMPLEMENTED -O2
-CC/ReleaseD/stdio_streambuf.o
c++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized
-D__STL_USE_GLIBC -D__STL_REAL_LOCALE_IMPLEMENTED -O2 -aseD/iostream.o
c++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
make: *** [obj/GCC/ReleaseD/iostream.o] Error 1

The ambigous, everpresent "error 1"...

Reproducible: Couldn't Reproduce
Steps to Reproduce:
1.Attempt to compile STLPort 4, using the 'gcc-glibc.mak' makefile
2.type 'make clean'
3.type 'make all'
	

Actual Results:  The compilation process began, but failed.  I was informed
(through the console) that contacting bugzilla wouild be a good idea.	

Expected Results:  The compilation process should have finished, successfully.

Comment 1 Jakub Jelinek 2001-02-25 20:16:03 UTC

g++ itself does not ever send SIGKILL to itself, so this had to be either
some other program killing it or may be kernel got into out of memory
situation and started to kill processes.
Please, make sure this dies reproducably on the same file (also check
if you aren't running with -j make option and that you have reasonable
amount of virtual memory available). If you see that cc1plus
process takes excessive amounts of memory, please rerun the g++ command
which causes this with additional -save-temps -v options and
write here full command line of cc1plus you see in the g++ output
plus attach here the preprocessed source (file with .ii extension
the command creates).

Comment 2 Kyle Jacobs 2001-02-25 23:13:43 UTC

Your most likely right about the kernel memory issue.  I was running the 
command under XFree86 & KDE2 (and real memory was at a premium).  The test 
system doesn't have more than about 4 megabytes of swap partition, and the 
error was NOT reproducible.  I was multitasking at the time, and during the 
reattempts, I was not.

Therefor, the bug was not reproducable under differing memory situations.  I 
think this can be chalked up to a lack of available RAM.