Bug 29346 - c++ internal Error: Killed (program cc1plus)
Summary: c++ internal Error: Killed (program cc1plus)
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-02-25 06:37 UTC by Kyle Jacobs
Modified: 2007-04-18 16:31 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2001-02-25 23:13:46 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.