[LLVMbugs] [Bug 19031] New: Small testcase uses extreme amount of memory if compiled with -g
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Mon Mar 3 13:05:24 PST 2014
http://llvm.org/bugs/show_bug.cgi?id=19031
Bug ID: 19031
Summary: Small testcase uses extreme amount of memory if
compiled with -g
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: dimitry at andric.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12180
--> http://llvm.org/bugs/attachment.cgi?id=12180&action=edit
Small testcase using way too much memory for its size
A post on the FreeBSD toolchain mailing list showed a clang crash due to OOM:
http://lists.freebsd.org/pipermail/freebsd-toolchain/2014-February/001125.html
the log of the build is here (crash is at the end):
http://beefy2.isc.freebsd.org/bulk/head-amd64-default/2014-02-28_01h43m56s/logs/arx-libertatis-1.0.3_2.log
The OP notes an RSS of 15GB. I did some creduce'ing on his sample files, using
clang trunk r202496, and ended up with the attached sample program, just ~100
lines of code. If you compile this with just -O2, it is very fast to compile,
and uses little memory:
$ time -l clang -cc1 -triple x86_64-unknown-freebsd11.0 -emit-obj
-mrelocation-model static -O2 too-much-mem.cpp
too-much-mem.cpp:40:1: warning: inline namespaces are a C++11 feature
inline namespace __1 {
^
1 warning generated.
0.04 real 0.02 user 0.00 sys
19020 maximum resident set size
42992 average shared memory size
101 average unshared data size
298 average unshared stack size
1057 page reclaims
0 page faults
0 swaps
0 block input operations
1 block output operations
20 messages sent
0 messages received
0 signals received
22 voluntary context switches
0 involuntary context switches
if you add -g, though, it suddenly balloons to ~2.5 GiB! E.g.:
$ time -l clang -cc1 -triple x86_64-unknown-freebsd11.0 -emit-obj
-mrelocation-model static -O2 -g too-much-mem.cpp
too-much-mem.cpp:40:1: warning: inline namespaces are a C++11 feature
inline namespace __1 {
^
1 warning generated.
7.87 real 4.26 user 3.53 sys
2661660 maximum resident set size
32178 average shared memory size
75 average unshared data size
255 average unshared stack size
1069959 page reclaims
0 page faults
0 swaps
0 block input operations
1 block output operations
27 messages sent
0 messages received
0 signals received
30 voluntary context switches
167 involuntary context switches
I know generating debug information always uses more memory, but this is a
little bit ridiculous. :-)
Also interesting is that removing the -mrelocation-model static helps:
$ /usr/bin/time -l clang -cc1 -triple x86_64-unknown-freebsd11.0 -emit-obj -O2
-g too-much-mem.cpp
too-much-mem.cpp:40:1: warning: inline namespaces are a C++11 feature
inline namespace __1 {
^
1 warning generated.
0.07 real 0.01 user 0.03 sys
19476 maximum resident set size
19346 average shared memory size
45 average unshared data size
153 average unshared stack size
1156 page reclaims
0 page faults
0 swaps
0 block input operations
1 block output operations
36 messages sent
0 messages received
0 signals received
38 voluntary context switches
0 involuntary context switches
So this seems to be some sort of bad interaction between the static relocation
model and debug information generation?
When building the original testcase from the mailing list, this is all even
worse, and it blows up my testing VM before it can compile, having used up at
least 8GB resident set size. Similarly to the minimized testcase, removing
-mrelocation-model static allows it to compile, within about 3.5 seconds, and
just 91 MiB of RSS.
I can also reproduce these results on Linux, btw, so it is not specifically
FreeBSD-related.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140303/1f9ad2ce/attachment.html>
More information about the llvm-bugs
mailing list