Как избежать сбоя gcc из-за нехватки памяти - PullRequest
Новая
       8

Как избежать сбоя gcc из-за нехватки памяти

0 голосов
/ 04 сентября 2018

Я продолжаю аварийно завершать работу gcc (из-за нехватки памяти) при попытке скомпилировать класс, который использует множество шаблонов функций, определенных в соответствующем файле .h для моего класса. У меня есть 6,4 ГБ памяти, когда я начинаю компиляцию этого файла cpp: 

$ 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,4 ГБ должно быть достаточно памяти для компиляции файла .cpp независимо от сложности файла. Я ошибаюсь здесь в этом мышлении?

EDIT. Вот прототипы функций в .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 на самом деле использует 6 ГБ для компиляции: 

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. Я увеличил объем подкачки до 8 ГБ, и теперь gcc использует чуть менее 8 ГБ при попытке скомпилировать этот файл: 

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 ++.

1 Ответ

0 голосов
/ 04 сентября 2018

Я лично считаю, что 6,4 ГБ должно быть достаточно памяти для компиляции файла .cpp независимо от сложности файла. Я не прав в этом мышлении?

Да. Случается, что шаблоны C ++ "случайно" завершены по Тьюрингу (см. this и прочитайте Тодда Л. Вельдхуйзена Шаблоны C ++ полностью завершены по Тьюрингу ).

Так вы не правы . Патологические программы на C ++ могут занимать произвольное (или даже бесконечное) количество времени и памяти для компиляции (и кодирование таких патологических программ на C ++ довольно просто).

Другими словами, разработчики программ на C ++ должны использовать шаблоны с большой осторожностью и скупостью. Довольно просто написать взрывной шаблон (с комбинаторным взрывом во время расширения шаблона). Когда вы кодируете шаблоны, вам нужно убедить себя (и в идеале, чтобы доказать), что их расширение занимает линейное (или ограниченное, или, по крайней мере, разумное) время и пространство, поэтому вам следует оценить время и пространство сложность из расширение шаблона.

Кстати, 8 гигабайт оперативной памяти не так много сегодня. Подумайте о том, чтобы купить больше оперативной памяти, увеличить пространство подкачки, закрыть все ненужные приложения ( IDE s, текстовые процессоры, веб-браузеры, JVM, ...), отключить отладочную информацию, снизить уровень оптимизации при компиляции вещи (и скомпилировать его в командной строке). Возможно, также может помочь обновление до GCC 8 . Попробуйте, возможно, также Clang .

И у вас могут быть ошибки в ваших шаблонах (например, неправильное или «бесконечное» рекурсивное или чрезмерное расширение).

Возможно, вы захотите использовать опции GCC C ++ подобно -ftemplate-depth (чтобы поймать шаблон слишком большой глубины).

...