Bug 141139 - gcc4 locks up system until killed by OOM killer
gcc4 locks up system until killed by OOM killer
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gcc4 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-29 11:25 EST by John Ellson
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-30 08:55:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sfvscanf.i produced by adding -save-temps to cc opts (140.00 KB, text/plain)
2004-11-29 11:29 EST, John Ellson
no flags Details

  None (edit)
Description John Ellson 2004-11-29 11:25:51 EST
Description of problem:
When making graphviz (http://www.graphviz.org/) one particular source
file, tools/sfio/sfvscanf.c, occasionally tickles some sort of memory
runaway in gcc4 which locks up the system for some minutes until cc1
is killed by the OOM killer.

This particular source file that tickles the bug is in stable code
that has probably not changed for years.

Re running make after the OOM has recovered is successful.

Problem seems to only occur on "first" invocation of make after some
time, or after reboot.

Problem seems to require other applications to be running on the
system, e.g firefox + thunderbird + metacity + x11.   Running from
console after reboot on a quiet system did not trigger the bug.

Problem is easier (or perhaps just quicker) to trigger with parallel
compiles using "make -j", but I've seen it happen without -j.

Version-Release number of selected component (if applicable):
gcc4-4.0.0-0.11
kernel-2.6.9-1.681_FC3

How reproducible:
Not 100%

Steps to Reproduce:
1. obtain graphviz sources from http://www.graphviz.org
2. ./confgure; make -j
3.

Actual results:
/usr/bin/gcc4 -DHAVE_CONFIG_H -I. -I. -I../.. -I../../tools/ast
-I/usr/local/include -Dvt_threaded=0 -save-temps -g -O2 -Wall -MT
sfvscanf.lo -MD -MP -MF .deps/sfvscanf.Tpo -c sfvscanf.c  -fPIC -DPIC
-o .libs/sfvscanf.o
gcc4: Internal error: Killed (program cc1)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [sfvscanf.lo] Error 1
make[4]: Leaving directory
`/home/ellson/FIX/Linux.i686/build/graphviz/tools/sfio'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/ellson/FIX/Linux.i686/build/graphviz/tools/sfio'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/ellson/FIX/Linux.i686/build/graphviz/tools'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ellson/FIX/Linux.i686/build/graphviz'
make: *** [all] Error 2

Expected results:
No OOM

Additional info:
/var/log/messages shows:
Nov 29 11:22:45 ellson kernel: oom-killer: gfp_mask=0x1d2
Nov 29 11:22:45 ellson kernel: DMA per-cpu:
Nov 29 11:22:45 ellson kernel: cpu 0 hot: low 2, high 6, batch 1
Nov 29 11:22:45 ellson kernel: cpu 0 cold: low 0, high 2, batch 1
Nov 29 11:22:45 ellson kernel: Normal per-cpu:
Nov 29 11:22:45 ellson kernel: cpu 0 hot: low 32, high 96, batch 16
Nov 29 11:22:45 ellson kernel: cpu 0 cold: low 0, high 32, batch 16
Nov 29 11:22:45 ellson kernel: HighMem per-cpu: empty
Nov 29 11:22:45 ellson kernel:
Nov 29 11:22:45 ellson kernel: Free pages:         704kB (0kB HighMem)
Nov 29 11:22:45 ellson kernel: Active:15506 inactive:97193 dirty:1
writeback:91150 unstable:0 free:176 slab:7185 mapped:22181 pagetables:1225
Nov 29 11:22:45 ellson kernel: DMA free:16kB min:20kB low:40kB
high:60kB active:0kB inactive:12168kB present:16384kB
Nov 29 11:22:46 ellson kernel: protections[]: 0 0 0
Nov 29 11:23:21 ellson kernel: Normal free:688kB min:696kB low:1392kB
high:2088kB active:62024kB inactive:376604kB present:506880kB
Nov 29 11:23:21 ellson kernel: protections[]: 0 0 0
Nov 29 11:23:21 ellson kernel: HighMem free:0kB min:128kB low:256kB
high:384kB active:0kB inactive:0kB present:0kB
Nov 29 11:23:21 ellson kernel: protections[]: 0 0 0
Nov 29 11:23:21 ellson kernel: DMA: 0*4kB 0*8kB 1*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 16kB
Nov 29 11:23:21 ellson kernel: Normal: 0*4kB 0*8kB 1*16kB 1*32kB
6*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 688kB
Nov 29 11:23:22 ellson kernel: HighMem: empty
Nov 29 11:23:22 ellson kernel: Swap cache: add 131483, delete 40018,
find 2134/2333, race 0+0
Nov 29 11:23:22 ellson kernel: Out of Memory: Killed process 17478 (cc1).
Comment 1 John Ellson 2004-11-29 11:29:59 EST
Created attachment 107548 [details]
sfvscanf.i produced by adding -save-temps to cc opts
Comment 2 Jakub Jelinek 2004-11-30 08:55:36 EST
Please retry with gcc4-4.0.0-0.13 from rawhide.
With gcc4-4.0.0-0.8 on x86_64 (-m32 -march=i386 -g -O2 -fPIC; so even bigger
memory consumption due to 64-bit HOST_WIDE_INT and 64-bit pointers), the peak
memory usage in sfvscanf goes to 780749k, with gcc4-4.0.0-0.13 it remains
at ~ 5701k of garbage collected memory.

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