如何避免由于内存不足而导致 gcc 崩溃答案

【问题标题】：How to avoid gcc crash due to lack of memory如何避免由于内存不足而导致 gcc 崩溃
【发布时间】：2018-09-04 17:35:20
【问题描述】：

当我尝试编译一个使用我的类的相应 .h 文件中定义的许多函数模板的类时，我不断崩溃 gcc（由于内存不足）。当我开始编译该 cpp 文件时，我有 6.4GB 的可用内存：

$ free -mh
                  total        used        free      shared  buff/cache   available
    Mem:           9.7G        3.1G        6.5G        260K        212M        6.4G
    Swap:          947M        887M         59M

这里是 gcc 的详细信息：

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-16ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as --with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)

这是编译该文件时崩溃前的内存情况：

$ free -mh
              total        used        free      shared  buff/cache   available
Mem:           9.7G        9.6G        113M        352K         58M        816K
Swap:          947M        947M          0B

以及崩溃详情：

c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
main.dir/build.make:127: recipe for target 'myclass.cpp.o' failed

我可以做些什么来避免这种情况（除了删除模板）？我个人认为无论文件多么复杂，6.4GB 的内存都应该足够编译一个 .cpp 文件。我的想法错了吗？

编辑。这是 .hpp 中的函数原型：

typedef std::shared_ptr<Object> ObjectPtr;

template<typename MapTypeT, typename KeyTypeT, typename ValueTypeT>
ObjectPtr InitMap(KeyTypeT key, ValueTypeT value, std::list<std::pair<ObjectPtr, ObjectPtr>> keyValuePairs); 
template<typename KeyTypeT, typename ValueTypeT>

ObjectPtr ConstructMap(KeyTypeT key, ValueTypeT value, std::list<std::pair<ObjectPtr, ObjectPtr>> keyValuePairs); // calls InitMap<std::unordered_map> and InitMap<std::map>

template<typename KeyTypeT>
ObjectPtr DeduceValue(KeyTypeT key, const ObjectPtr &anyValue, const std::list<std::pair<ObjectPtr, ObjectPtr>> &keyValuePairs); // calls ConstructMap<KeyTypeT, ValueTypeT> 

ObjectPtr CreateMap(std::list<std::pair<ObjectPtr, ObjectPtr>> keyValuePairs); // calls DeduceValue<KeyTypeT>

EDIT2.

这是 gcc 实际使用 6GB 进行编译的证据：

Tasks: 295 total,   4 running, 223 sleeping,   0 stopped,   0 zombie
%Cpu(s): 57.0 us,  2.3 sy,  0.0 ni, 40.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 10208840 total,   138780 free,  9850648 used,   219412 buff/cache
KiB Swap:   969960 total,       28 free,   969932 used.   104132 avail Mem 

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND    
 91917 mfonnem+  20   0 6381472 6.029g  14936 R  99.3 61.9   2:50.04 cc1plus    
 90603 mfonnem+  20   0 5300888 1.243g  16796 S   8.6 12.8   5:42.14 java

编辑 3. 我将交换内存增加到 8GB，现在 gcc 在尝试编译该文件时使用了不到 8GB：

top - 00:13:27 up  5:25,  1 user,  load average: 2.55, 2.02, 1.92
Tasks: 298 total,   3 running, 226 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3.9 us, 16.5 sy,  0.0 ni, 13.4 id, 42.9 wa,  0.0 hi, 23.4 si,  0.0 st
KiB Mem : 10208832 total,   111252 free, 10015484 used,    82096 buff/cache
KiB Swap:  8388604 total,  3069856 free,  5318748 used.     7256 avail Mem 

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND    
 25578   20   0 9071708 7.498g    412 R  27.2 77.0   5:27.26 cc1plus

最终，它会报告：

internal compiler error: Segmentation fault
     }
     ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.

EDIT4.可以用 clang++ 编译。

【问题讨论】：

我们需要查看模板。
提醒：仅仅因为你的机器有 6.4GB，并不意味着g++ 可以使用它。内存在所有正在运行的程序和服务之间共享。
您的模板是否被递归定义，如果是，递归是否正确终止？
"不管文件有多复杂。" 所以你认为一切都应该能够在 O(1) 内存中编译？
@ThomasMatthews 之类的？每个进程都有自己的进程空间。此外，大概他的计算机实际上并没有 6.4GB 的 RAM - 这似乎更有可能是他开始之前的空闲量。

标签： c++ templates gcc g++

【解决方案1】：

我个人认为 6.4GB 的内存应该足够编译一个 .cpp 文件，无论文件多么复杂。我的想法错了吗？

是的。 C++ 模板恰好是“意外”图灵完备的（请参阅 this 并阅读 Todd L. Veldhuizen C++ Templates are Turing Complete 论文）。

所以你错了。病态的 C++ 程序可以花费任意（甚至无限）的时间和内存来编译（并且编写这种病态的 C++ 程序非常容易）。

换句话说，C++ 程序编写者在使用模板时应该非常谨慎和简约。编写一个爆炸性模板非常容易（在模板扩展时使用combinatorial explosion）。当您编写模板时，您需要说服自己（最好是证明）它们的扩展需要线性（或有界，或至少是合理的）时间和空间，因此您应该估计模板扩展的时间和空间complexity。

顺便说一句，今天 8 GB 的 RAM 并不多。考虑购买更多 RAM，增加交换空间，关闭所有非必要的应用程序（IDEs，字处理器，Web 浏览器，JVM，...），禁用调试信息，降低优化级别，编译这些东西（并编译它在命令行上）。也许升级到GCC 8 也可能有所帮助。也可以试试Clang。

而且您的模板中可能存在错误（例如，不正确或“无限”递归或过度扩展）。

您可能想使用GCC C++ options 和-ftemplate-depth 一样（捕获模板深度过大）。

【讨论】：

禁用调试比删除优化更能减少内存使用。
@Basile Starynkevitch 这并不是对 gcc 的攻击。我意识到编译很困难，因为我之前编写过非生产级编译器。但是，6GB 的单个目标文件对我来说似乎是很多内存。顺便说一句，模板不会递归调用自己。
请不要评论您对正在发生的事情的看法。而是发布minimal reproducible example
@xaxxon 我不相信我发布了 gcc 在崩溃时使用 6GB 内存的证据。请查看顶部的输出。
@markf78 MCVE 的真正美妙之处在于您可能会完成一半，看到问题，给自己一记耳光，然后自己解决问题。一个好的 MCVE 可能是残酷和耗时的，但该死的有效吗？

【解决方案2】：

我通常发现添加更多交换空间通常可以解决 GCC 的问题。请参阅here 了解如何添加交换空间——尽管您付出的代价是编译/链接时间可能需要数小时。至于为什么，我怀疑模板的“修改规则”是杀手锏，尽管很难证明。转储符号（使用 -Q 标志）可能会帮助您更好地理解。

修复构建的想法

您可能会发现将符号移动到匿名命名空间会加快速度（从导出的符号中删除它们）
您还可能会发现 UnityBuild 方法会有所帮助，因为它可以在创建符号时做更多的工作。

很抱歉没有提供更多帮助，但它可能会给你一些想法。如果您发现“-Q”有什么有趣的地方，请发布结果。

【讨论】：