Bug 164873 - while compiling cinelerra for redhat gcc cc1 component crashes with internal errors
Summary: while compiling cinelerra for redhat gcc cc1 component crashes with internal ...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc4
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL: http://rafb.net/paste/results/KH5tMN1...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-02 06:12 UTC by Supreet Sethi
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-08-10 16:05:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
preprocessed i file (259.71 KB, application/octet-stream)
2005-08-10 06:58 UTC, Supreet Sethi
no flags Details
asm file (2.46 MB, application/octet-stream)
2005-08-10 07:00 UTC, Supreet Sethi
no flags Details

Description Supreet Sethi 2005-08-02 06:12:50 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
cinelerra has been compiling normally with gcc 3.2.3. I have been producing RPM packages for cinelerra using gcc 3.2.3. I tried shifting to FC4 from RHEL4, the GCC 4 gets killed at certain point while compiling.

I am using cinelerra from cvs.cinelerra.org

checkout on 1930 IST

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. ./configure
2.  gmake

  

Actual Results:  gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libmpeg3 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_FIREWIRE -I/usr/include/ffmpeg -I/usr/include/mjpegtools -I/usr/include/mjpegtools/mpeg2enc -I/usr/include/mjpegtools/mplex -DENCORE_INCLUDE=\"encore50/encore.h\" -g -O2 -MT cmodel_default.lo -MD -MP -MF .deps/cmodel_default.Tpo -c cmodel_default.c  -fPIC -DPIC -o .libs/cmodel_default.o
gcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
gmake[3]: *** [cmodel_default.lo] Error 1
gmake[3]: Leaving directory `/home/supreet/cine/cinelerra/hvirtual/quicktime'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/home/supreet/cine/cinelerra/hvirtual/quicktime'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/supreet/cine/cinelerra/hvirtual'
gmake: *** [all] Error 2


Expected Results:  as above

Additional info:

packages used on these machine are RPM form, mostly from official repository or from freshrpms. Can provide detailed list if required

Comment 1 Jakub Jelinek 2005-08-06 10:25:03 UTC
Please attach preprocessed source on which this happens (you can use e.g.
GCC -save-temps option to create it).
How much RAM do you have?  The above error means the kernel OOM killer killed cc1
process, probably because it tried to use more memory than the system could give
to it.  If GCC used unreasonably too much memory, it would be GCC bug, otherwise
not.

Comment 2 Supreet Sethi 2005-08-10 06:58:56 UTC
Created attachment 117595 [details]
preprocessed i file

preprocessed i file

Comment 3 Supreet Sethi 2005-08-10 07:00:38 UTC
Created attachment 117596 [details]
asm file

Comment 4 Supreet Sethi 2005-08-10 09:30:42 UTC
the laptop has 256 MB RAM and 512 MB swap. and yes, it is happening because of
OOM killer is kicking in. Because Firefox instance also gets killed when I compile.

Comment 5 Jakub Jelinek 2005-08-10 16:05:10 UTC
Can't reproduce with gcc-4.0.1-4.fc4:

gcc -m32 -O2 -g 164873.i -S -fPIC -fmem-report
Memory still allocated at the end of the compilation process
Size   Allocated        Used    Overhead
8           2192k       2189k         51k
16          2084k       2083k         32k
32          6576k       6572k         77k
64           540k        538k       5400
128         8192        8192          72
256           24k         22k        192
512          172k        167k       1376
1024          32k         27k        256
2048          68k         60k        544
4096          48k         40k        384
8192         104k        104k        416
16384        224k        224k        448
32768        800k        800k        800
65536        576k        512k        288
131072       1408k       1408k        352
262144       1024k       1024k        128
524288        512k        512k         32
52          7924k       6893k         77k
108         8792k       8573k         77k
24          4228k       4208k         53k
36            13M         13M        152k
12            14M         14M        262k
40          4328k       3977k         46k
Total         69M         67M        841k

String pool
entries         15319
identifiers     15319 (100.00%)
slots           32768
bytes           144k (18k overhead)
table size      128k
coll/search     1.3227
ins/search      0.1331
avg. entry      9.65 bytes (+/- 3.17)
longest entry   40

??? tree nodes created

(No per-node statistics)
Type hash: size 1021, 294 elements, 0.161579 collisions

In top the VIRT consumption of cc1 goes to ~ 110M at most.
That doesn't seem unreasonable, given that cmodel_default function is very large,
with over 4000 basic blocks.


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