[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