Для интерактивного подхода (часто более безопасного):
Если в текущем каталоге есть файлы со специальными именами.
Вы можете использовать rm ./
, а затем Tab Tab , чтобы перечислить файлы, затем вы можете выбрать файл и удалить его.
Посетив лекцию по HPC и проведя небольшое исследование, я получил ответ.
Похоже, что ядро выделяет определенный объем памяти процессам компиляции. Эта функция помогает в некоторых случаях, когда могут возникать баги и те начинают выделять неоправданно большие объемы памяти. Но иногда для компиляции требуется больше памяти, чем обычно, и начинаются ошибки.
Затем с помощью следующей команды выделяется неограниченный объем памяти для компиляции.
ulimit -s unlimited
Теперь все работает нормально.
Спасибо @steeldriver за дополнительные вопросы.
Обходной путь ulimit -s unlimited
не полностью решил мою проблему. Был дополнительный сбой, вызванный защитой стека gcc :
# cat TESTING/snep.out
*** stack smashing detected ***: <unknown> terminated
IOT Trap
Tests of the Nonsymmetric Eigenvalue Problem routines
Чтобы отключить защиту от разрушения стека, измените строку CFLAGS в файле make.inc на:
CFLAGS = -O3 -I$(TOPDIR)/INCLUDE -fno-stack-protector
Затем make clean
и make all
.
Очень возможно, что детектор разрушения стека gcc обнаруживает здесь настоящие ошибки памяти, некоторые комментарии в этом отчете об ошибке предполагают, что некоторые из тестов имеют off -на -1 ошибки, когда индексирует некоторые массивы, поэтому, возможно, стоит попробовать более позднюю версию lapack, которая включает исправления этой ошибки, и, если это все еще не исправлено, поднять ошибку вверх по течению.
(Между прочим, я также столкнулся с другой ошибкой сборки :она не может быть собрана с помощью параллельного make, то есть make -j16 all
, но работает со стандартным одиночным процессом make all
.)
У меня была такая же проблема. Я попробовал обходной путь ulimit -s unlimited
, но при запуске теста, а не при компиляции. И все испытания теперь пройдены!