You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Extended Description
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.
The text was updated successfully, but these errors were encountered: