Пропадают процессы, не закончившись

Какая может быть «нештатная» ситуация в протоколе записи на диск? Как она может молча выбросить процесс? Я такого представить не могу.

Может и не в этом дело. Может процесс записи и не вашего процесса. Но вы сами утверждаете, что началось после трима. Косвенно предположим, что не после, а вследствие. Тогда для проверки заменить железяку? Даже две железяки - память и поставьте жесткий диск. НЕ ссд, так как логика их контроллера пониманию не поддается.

Я не утверждаю, а подозреваю, потому что это один раз произошло сразу после fstrim (видел top до и после), а то, что вспомнил (было такое и на другом компе), тоже в то время баловался fstrim с параметром -v. До этого как простой пользователь о нем не знал, а мне здесь объяснили, что это не может повлиять.
Однако, специально несколько раз я попробовал fstrim-мом во время счета (когда задачи только стартовали) повторить ситуацию, но ничего не произошло. Доказательств на данный момент нет, но и опровержения тоже.
Заменить SSD на HHD, я не нахожу удачной идеей, потому что Система остается на SSD и чистоты эксперимента не будет, а, второе, будет постоянное «стрекотание» HHD от обменов, раздражающее слух и замедляющее 10 процессов, которые начинают вставать в очередь к диску.

Проверил, бан за политоту у вас и оскорбления после предупреждения о политоте, заслуженный. Добавляю вас в игнор, общаться со школьником скучно.

Ну на нет и суда нет. А la у вас и так четыре.

la -?

fstrim нужно запускать по таймеру раз в неделю. И не во время максимальной нагрузки на систему. Не понимаю зачем его дёргать руками.

Нужно писать в лог код завершения программы. На баше код можно вывести командой echo $?. Её нужно написать в скрипте сразу после команды запуска программы, которая падает. Вроде бы если программа убита сигналом, то будет соответствующий код. И по нему станет понятна причина.

Если запуск программы происходит в контейнере, то нужно разобраться как там происходит логирование. Оно скорее всего не попадает в журнал хоста.

Спасибо, я видел уже такой совет, но не могу его «вкурить».
Если я запускаю задачу:
nohup xxx&
то после ее завершения и так появляется код завершения Done (0) или, например, Exit 2 ? В котнейнере тоже самое.

Но в описанном случае в окне терминала я ничего не вижу подобного, файл nohup.out также не создается.

Предлагается открыть 10 окон и напрямую запускать?

Написать скрипт start.sh

/path/to/app
echo "exit code: $?" > /path/to/log.txt

Где app это проблемное приложение. Скрипт запускать через nohup bash start.sh &. Чтобы проверить работу этой схемы можно временно заменить /path/to/app на /bin/false. Код завершения в логе должен быть 1.

А что за контейнеры? Например в докере по умолчанию стоит маленький размер шареной памяти и процессы, которым требуется её много не работают без ручной настройки.

Я только юзер, знаю только, что управляет podman. Смысл в том, чтобы некий framework скомпилированный под одной системой пускать на любом линухе.

Я понял, это попытка сохранить копию кода завершения, если он образуется.
Другой вопрос, а что даст в смысле понимания проблемы, например, код 2 или 1?

Если приложение убито каким то сигналом, то код будет больше 128. И по нему можно определить какой конкретно сигнал был.

128+n: Fatal error signal "n", где n это
SIGHUP           1
SIGINT           2
SIGQUIT          3
SIGILL           4
и т.д.

Спасибо, попробую, по идее при таком запуске задачи, если все идет по правилам, а на это, все-таки, указывает сохранность других процессов, то какой-то код должен остаться для истории. Даже интересно. Почему его не было в терминале, это вопрос уже следующего порядка.

даже самые отъявленные лентяи давно уже спрашивают не у гугла, а у гпт. тут

Специально запустил 10 задач, чтобы в случае «пропажи» попытаться отловить ее код завершения. Через полутора суток перестала считаться одна задача - тор ее перестал видеть (или она где-то внизу). Через ps отыскал - она оказалась спящей, ждущей ресурсов.

xxx@vxx01:~$ ps -aux|grep rndAc|grep bin
xxx        32263 60.5  4.6 958304 367248 pts/0   R    июл26 1416:50 /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe -splash -b -l -q rndAc.c(50,1)
xxx        32517 60.6  5.1 954508 403452 pts/0   R    июл26 1416:02 /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe -splash -b -l -q rndAc.c(50,2)
xxx        32602 60.5  6.4 965204 507352 pts/0   R    июл26 1413:35 /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe -splash -b -l -q rndAc.c(50,3)
xxx        33988 60.3  6.5 966164 516100 ?       R    июл26 1402:28 /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe -splash -b -l -q rndAc.c(50,5)
xxx        33989 60.3  6.6 964484 518316 ?       R    июл26 1402:15 /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe -splash -b -l -q rndAc.c(50,4)
xxx        33990 54.5  6.2 938000 490528 ?       S    июл26 1268:02 /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe -splash -b -l -q rndAc.c(50,9)
xxx        33991 60.3  6.6 959192 519576 ?       R    июл26 1401:58 /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe -splash -b -l -q rndAc.c(50,7)
xxx        33992 60.3  6.6 967248 523072 ?       R    июл26 1402:04 /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe -splash -b -l -q rndAc.c(50,6)
xxx        33993 60.3  6.5 968316 514232 ?       R    июл26 1402:11 /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe -splash -b -l -q rndAc.c(50,10)
xxx        33994 60.2  6.4 954768 510264 ?       R    июл26 1400:31 /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe -splash -b -l -q rndAc.c(50,8)

Может кто прокомментировать ситуацию?

Я предполагаю, что не закончился какой-то обмен с диском, и задача будет ждать его окончания (прихода соответствующего прерывания) вечно? Есть ли возможность «подтолкнуть» ее?

Чисто ли это ошибка железа, почему система не выдает таймаут и сообщение об ошибке обмена?

Можно ли выудить дополнительную информацию?

Через полутора суток перестала считаться одна задача - тор ее перестал видеть

Т.е. твои процессы никуда не пропадали, а ты их просто в топе не видел? Ну ты красавчик! 50 лет опыта!

Полегчало, умнейший во всех ситуациях Вы наш?
А по существу вопроса ничего, только по личности. Вот она суть сисадмина - не бескорыстная помощь, а наслаждение чужими ошибками.

Поймите, милейший Вы наш,

у меня задача создать алгоритм решения определенной задачи - основная цель, а не выискивание ляп в ОС и железе

Отсутствие обработки нештатных ситуаций вашей программы это «ляп в ОС и железе»?

обработки нештатных ситуаций вашей программы

Что Вы понимаете под этим?

Лично я понимаю: деление на 0, arcsin от числа больше 1, выход индекса массива за его границы. Отключение электричества могу посчитать за нештатную ситуацию, чтобы создать контрольную точку, но зависание обмена при записи данных на диск - это штатная ситуация для ОС, я не прав?

Если процесс висит на операции с файлом, то можно попробовать посмотреть что это за файл. Может появятся мысли куда дальше копать. В /proc/<pid зависшего процесса>/fd/ перебрать все дескрипторы и на каждый сделать вызов команды readlink. Какой то из них будет виновником. У меня сейчас нет компьютера под рукой, проверить эту идею не могу.

Так же зависание может быть из-за deadlock потоков.

Ещё вижу, что процесс запущен из примонтированной сетевой папки. Это тоже не прибавит стабильности в случае сбоев в локальной сети.

не правы, Валентин Александрович.

Я посмотрел на все файлы, приписанные процессу.

3 файла /cvmfs, нужные для комиляции и сборки бинарника. Но так как этот процесс происходил не первый раз, то (по информации от наших системщиков, сделавших framework) они должны быть в cash-памяти моего компа, и нужны только в начальный момент сборки бинарника.

4 рабочих файла, на 2 пишется и считывается информация, на 2 только пишутся результаты.

nohup.out c временной меткой, относящейся к времени запуска задач и единый для всех 10 задач. В этом файле есть информация об ошибках обмена с файлом задачи, работающей, а не спящей. Информация из framework, т.е. ее уровень выше системного, связана с unzip. Я могу сделать вывод, что информация в этом файле к спящему процессу не имеет отношения.

?

Потому как все ПО Вы сознательно используете на свой страх и риск.

Вы ушли в кусты от ответа на вопрос - что такое «нештатная ситуация», и какого уровня они бывают? Вместо этого пустая фраза про «страх и риск».

Можно подключиться отладчиком к процессу и посмотреть стектрейсы потоков в юзерспейсе.

Можно посмотреть в /proc/PID/task/*/stack стектрейсы потоков в ядре.

Может в программе логическая ошибка. Например, программа читает stdin вместо файла, а stdin не оторван от терминала.

Если устройство не отвечает, хотя должно - это нештатная ситуация. И предусмотреть это у программиста есть и документация и коды ошибок. Вы тоже не слышите, что Вам говорят.

программа НЕ читает stdin

cat /proc/33990/task/33990/stack
[<0>] futex_wait_queue_me+0xa8/0x110
[<0>] futex_wait+0x105/0x260
[<0>] do_futex+0x1ba/0x880
[<0>] __x64_sys_futex+0x7b/0x1c0
[<0>] do_syscall_64+0x5c/0xc0
[<0>] entry_SYSCALL_64_after_hwframe+0x61/0xcb

К сожалению, для меня это «китайская грамота»

__x64_sys_futex это сискол futex. Значит твой юзерспейс код вызвал какой-то из блокирующих вызовов pthread_mutex_lock, pthread_cond_wait, и т.п. Подключись отладчиком к процессу и посмотри, что делает твой код:

sh> gdb /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe
gdb> attach 33990
gdb> thread apply all bt -full

«Все смешалось в доме Облонских…»(с)

Умиляет: «у программиста есть и документация и коды ошибок»

(gdb) attach 33990 Attaching to program: /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe, process 33990 ptrace: Operation not permitted.

Наверное yama мешает https://www.kernel.org/doc/Documentation/security/Yama.txt. Попробуй выключить sudo sysctl kernel.yama.ptrace_scope=0.

Да, так и было, выдалoсь много иероглифовно криминала (error) не нашел

#19 0x00007f144101b2ce in TBasket::WriteBuffer (this=<optimized out>) at /cvmfs/nica.jinr.ru/sw/SOURCES/ROOT/v6.26.10/v6-26-10/tree/tree/src/TBasket.cxx:1245
        i = 0
        nbuffers = 1
        buflen = 31478
        objbuf = 0x128bfda5 "\300Tmn\212\254\352\b\300TP/v\352\340\302\300T3vn\344\346F\300T\026i\006!\003 \300S\363\370\202\062\250p\300T*", <incomplete sequence \365>
        bufcur = 0x12ad3d75 "ZL\b u"
        kWrite = 1
        file = 0x129a1350
        sentry = {_M_device = <optimized out>, _M_owns = false}
        entryOffset = <optimized out>
        nout = 0
        noutot = 0
        bufmax = 31356
        nzip = 0
        cxlevel = <optimized out>
        cxAlgorithm = ROOT::RCompressionSetting::EAlgorithm::kZLIB
        nBytes = <optimized out>
#20 0x00007f1441028d97 in operator() (__closure=__closure@entry=0x7ffca76e8db0) at /cvmfs/nica.jinr.ru/sw/SOURCES/ROOT/v6.26.10/v6-26-10/tree/tree/src/TBranch.cxx:3147
        nout = <optimized out>
        addbytes = <optimized out>
        reusebasket = <optimized out>
        basket = 0x129fc9a0
        this = 0x129a3060
        where = 75
#21 0x00007f1441029180 in TBranch::WriteBasketImpl (this=0x129a3060, basket=0x129fc9a0, where=75, imtHelper=0x0) at /cvmfs/nica.jinr.ru/sw/SOURCES/ROOT/v6.26.10/v6-26-10/tree/tree/src/TBranch.cxx:3202
        nevbuf = <optimized out>
        doUpdates = {__basket = 0x129fc9a0, __this = 0x129a3060, __where = 75}
#22 0x00007f14410293f4 in TBranch::FillImpl (this=0x129a3060, imtHelper=0x0) at /cvmfs/nica.jinr.ru/sw/SOURCES/ROOT/v6.26.10/v6-26-10/tree/tree/src/TBranch.cxx:923
        nout = <optimized out>
        basket = 0x129fc9a0
        buf = 0x129fcab0
        nsize = 212
        lnew = 31221
        nbytes = 712
        noFlushAtCluster = true
#23 0x00007f144109f870 in TTree::Fill (this=<optimized out>) at /cvmfs/nica.jinr.ru/sw/SOURCES/ROOT/v6.26.10/v6-26-10/tree/tree/src/TTree.cxx:4608
        branch = 0x129a3060
        i = 11
        nbytes = 512
        nwrite = <optimized out>
        nerror = 0
        nbranches = <optimized out>
        useIMT = <optimized out>
        imtHelper = {fBytes = {<std::__atomic_base<long long>> = {static _S_alignment = 8, _M_i = 0}, static is_always_lock_free = true}, fNerrors = {<std::__atomic_base<int>> = {static _S_alignment = 4, _M_i = 0}, static is_always_lock_free = true}, fGroup = {_M_t = {<std::__uniq_ptr_impl<ROOT::Experimental::TTaskGroup, std::default_delete<ROOT::Experimental::TTaskGroup> >> = {_M_t = {<std::_Tuple_impl<0, ROOT::Experimental::TTaskGroup*, std::default_delete<ROOT::Experimental::TTaskGroup> >> = {<std::_Tuple_impl<1, std::default_delete<ROOT::Experimental::TTaskGroup> >> = {<std::_Head_base<1, std::default_delete<ROOT::Experimental::TTaskGroup>, true>> = {<std::default_delete<ROOT::Experimental::TTaskGroup>> = {<No data fields>}, <No data fields>}, <No data fields>}, <std::_Head_base<0, ROOT::Experimental::TTaskGroup*, false>> = {_M_head_impl = 0x0}, <No data fields>}, <No data fields>}}, <No data fields>}}}
        autoFlush = <optimized out>
        autoSave = <optimized out>
#24 0x00007f143e996223 in RecoMiniMC::reco() () from /home/xxx/mpd/lib/libalignment.so.18.6.9
No symbol table info available.
#25 0x00007f145a474376 in ?? ()
No symbol table info available.
#26 0x0000000012255c20 in ?? ()
No symbol table info available.
#27 0x00007f145a5998d4 in ?? ()
No symbol table info available.
#28 0x00007f145a599427 in ?? ()
No symbol table info available.
#29 0x000000001229dac0 in ?? ()
No symbol table info available.
#30 0x00007ffca76e94b8 in ?? ()
No symbol table info available.
#31 0x0000000000000075 in ?? ()
No symbol table info available.
#32 0x00007ffca76e9630 in ?? ()
No symbol table info available.
#33 0x00007f14593e07d9 in __GI__IO_vfscanf () from /lib64/libc.so.6
No symbol table info available.
#34 0xbf515e76ccf16a61 in ?? ()
No symbol table info available.
#35 0x3f3395b54de41299 in ?? ()
No symbol table info available.
#36 0x3f55a4c45201ffa2 in ?? ()
No symbol table info available.
#37 0x3f494fccb0538e7b in ?? ()
No symbol table info available.
#38 0x3f4cbbc36779b30f in ?? ()
No symbol table info available.
#39 0x3f547b0e3ea5f951 in ?? ()
No symbol table info available.
#40 0x3f40389b2c335a0b in ?? ()
No symbol table info available.
#41 0x3f07373f06bbc410 in ?? ()
No symbol table info available.
#42 0xbf4e62eaccafa316 in ?? ()
No symbol table info available.
#43 0xbf53a219deb49f6d in ?? ()
No symbol table info available.
#44 0xbf506a646630033b in ?? ()
No symbol table info available.
#45 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb) 

А где же стекфреймы с #0 до #18? Ведь причина то где-то на макушке стека вызовов, а не в хвосте.

Здесь я маханулся, только сейчас понял. Та часть вывода gdb уже недоступна, то окно было закрыто, а теперь:

warning: process 33990 is already traced by process 194566
ptrace: Operation not permitted.
(gdb) thread apply all bt -full
(gdb)

Полный вывод не умещался в рамках форума, и я его неудачно секвестировал.

Первым пунктом была библиотека типа libso6 c с двоичными адресами и все следующие тоже из каких-то стандартных библиотек.

Жалко, хотелось разобраться в причине останова задачи, тем более остальные 9, близнецы братья, успешно завершились после почти 2х суток.

Главный вопрос, на который хотелось знать ответ, - может ли по большому счету система НАВСЕГДА подвешивать задачу, а в данном случае это скорее всего ожидание прерывания о завершении обмена

Это не система, а твоё приложение. Оно сделало какой-то библиотечный вызов, который привёл к блокирующемуся системному вызову futex. Найди процесс gdb, убей его sigterm-ом, запусти новый gdb, приаттачься ещё раз, посмотри стектрейс ещё раз.

А я знаю,в чем дело,но не скажу, потому что ты форумчанам хамишь :P

«Не верю!»(с) - К.Станиславский

Посмотрел, что такое futex. Понял, что в каких-то случаях оно может отправить процесс спать. К сожалению, пояснений такого действия не попалось. Остается вопрос - зачем, при каких условиях возникает «вечный сон»?

Thread 1 (Thread 0x7f145a595a40 (LWP 33990) "root.exe"):
#0  0x00007f14594937fc in __lll_lock_wait_private () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007f145940fba2 in _L_lock_16654 () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007f145940c7e3 in malloc () from /lib64/libc.so.6
No symbol table info available.
#3  0x00007f1459d2d1f5 in operator new (sz=23) at ../../../../gcc/libstdc++-v3/libsupc++/new_op.cc:50
        p = <optimized out>
#4  0x00007f145a0cd94a in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*> (__end=0x7ffca76e8316 "", __beg=0x7ffca76e8300 "segmentation violation", this=0x7ffca76e8260) at /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/GCC-Toolchain/v10.2.0-alice2-3/include/c++/10.2.0/bits/basic_string.tcc:219
        __dnew = 22
        __dnew = <optimized out>
#5  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*> (__end=0x7ffca76e8316 "", __beg=0x7ffca76e8300 "segmentation violation", this=0x7ffca76e8260) at /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/GCC-Toolchain/v10.2.0-alice2-3/include/c++/10.2.0/bits/basic_string.h:247
--Type <RET> for more, q to quit, c to continue without paging--c
No locals.
#6  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*> (__end=0x7ffca76e8316 "", __beg=0x7ffca76e8300 "segmentation violation", this=0x7ffca76e8260) at /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/GCC-Toolchain/v10.2.0-alice2-3/include/c++/10.2.0/bits/basic_string.h:266
No locals.
#7  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<std::allocator<char> > (__a=..., __s=0x7ffca76e8300 "segmentation violation", this=0x7ffca76e8260) at /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/GCC-Toolchain/v10.2.0-alice2-3/include/c++/10.2.0/bits/basic_string.h:527
No locals.
#8  ErrorHandler(Int_t, const char *, const char *, typedef __va_list_tag __va_list_tag *) (level=4000, location=0x7f145a2863b8 "TUnixSystem::DispatchSignals", fmt=0x7ffca76e8270 "", ap=0x7ffca76e8260) at /cvmfs/nica.jinr.ru/sw/SOURCES/ROOT/v6.26.10/v6-26-10/core/foundation/src/TError.cxx:140
        buf_size = 256
        buf_storage = 0x0
        small_buf = "segmentation violation", '\000' <repeats 233 times>
        buf = 0x7ffca76e8300 "segmentation violation"
        ap_copy = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7ffca76e8520, reg_save_area = 0x7ffca76e8460}}
        n = <optimized out>
        bp = {static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7ffca76e8270 ""}, _M_string_length = 0, {_M_local_buf = '\000' <repeats 15 times>, _M_allocated_capacity = 0}}
#9  0x00007f145a0ce068 in Break (location=location@entry=0x7f145a2863b8 "TUnixSystem::DispatchSignals", fmt=fmt@entry=0x7f145a26fe88 "%s") at /cvmfs/nica.jinr.ru/sw/SOURCES/ROOT/v6.26.10/v6-26-10/core/foundation/src/TError.cxx:213
        ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7ffca76e8520, reg_save_area = 0x7ffca76e8460}}
#10 0x00007f145a134ea8 in TUnixSystem::DispatchSignals (this=0x1936570, sig=kSigSegmentationViolation) at /cvmfs/nica.jinr.ru/sw/SOURCES/ROOT/v6.26.10/v6-26-10/core/unix/src/TUnixSystem.cxx:3614
No locals.
#11 <signal handler called>
No symbol table info available.
#12 0x00007f14594097a2 in _int_malloc () from /lib64/libc.so.6
No symbol table info available.
#13 0x00007f145940c78c in malloc () from /lib64/libc.so.6
No symbol table info available.
#14 0x00007f145a55dc3c in deflateInit2_ () from /cvmfs/nica.jinr.ru/sw/slc7_x86-64/zlib/v1.2.8-3/lib/libz.so.1
No symbol table info available.
#15 0x00007f145a55ddde in deflateInit_ () from /cvmfs/nica.jinr.ru/sw/slc7_x86-64/zlib/v1.2.8-3/lib/libz.so.1
No symbol table info available.
#16 0x00007f145a0d2d56 in R__zipZLIB (irep=0x7ffca76e8d38, tgt=0x12ad3d75 "ZL\b u", tgtsize=0x7ffca76e8d3c, src=0x128bfda5 "\300Tmn\212\254\352\b\300TP/v\352\340\302\300T3vn\344\346F\300T\026i\006!\003 \300S\363\370\202\062\250p\300T*", <incomplete sequence \365>, srcsize=0x7ffca76e8d3c, cxlevel=<optimized out>) at /cvmfs/nica.jinr.ru/sw/SOURCES/ROOT/v6.26.10/v6-26-10/core/zip/src/RZip.cxx:207
        err = <optimized out>
        stream = {next_in = 0x128bfda5 "\300Tmn\212\254\352\b\300TP/v\352\340\302\300T3vn\344\346F\300T\026i\006!\003 \300S\363\370\202\062\250p\300T*", <incomplete sequence \365>, avail_in = 31356, total_in = 4607182418800017408, next_out = 0x12ad3d7e "x\001<[w<U\377\377G%\204\062Cvdf\357\371\262\327\275ܽl\211\226\250\264TF\211H\222\"+\242\222T>\025I\250^E\222J*)\rR\022\225\021\022\022\277\363\375\347\367\327\363q\357\071\347r\317=\357\327\373\365\034/t\330I\321T)s\301", avail_out = 31356, total_out = 139725376907104, msg = 0x0, state = 0x12a964c0, zalloc = 0x7f145a5642d0 <zcalloc>, zfree = 0x7f145a5642e0 <zcfree>, opaque = 0x0, data_type = 0, adler = 0, reserved = 139725386722408}
        method = 8
        l_in_size = <optimized out>
        l_out_size = <optimized out>
        err = <optimized out>
        method = <optimized out>
        stream = {next_in = <optimized out>, avail_in = <optimized out>, total_in = <optimized out>, next_out = <optimized out>, avail_out = <optimized out>, total_out = <optimized out>, msg = <optimized out>, state = <optimized out>, zalloc = <optimized out>, zfree = <optimized out>, opaque = <optimized out>, data_type = <optimized out>, adler = <optimized out>, reserved = <optimized out>}
        l_in_size = <optimized out>
        l_out_size = <optimized out>
#17 R__zipMultipleAlgorithm (compressionAlgorithm=<optimized out>, irep=0x7ffca76e8d38, tgt=0x12ad3d75 "ZL\b u", tgtsize=0x7ffca76e8d3c, src=0x128bfda5 "\300Tmn\212\254\352\b\300TP/v\352\340\302\300T3vn\344\346F\300T\026i\006!\003 \300S\363\370\202\062\250p\300T*", <incomplete sequence \365>, srcsize=0x7ffca76e8d3c, cxlevel=32532) at /cvmfs/nica.jinr.ru/sw/SOURCES/ROOT/v6.26.10/v6-26-10/core/zip/src/RZip.cxx:109
No locals.
#18 R__zipMultipleAlgorithm (cxlevel=cxlevel@entry=1, srcsize=srcsize@entry=0x7ffca76e8d3c, src=src@entry=0x128bfda5 "\300Tmn\212\254\352\b\300TP/v\352\340\302\300T3vn\344\346F\300T\026i\006!\003 \300S\363\370\202\062\250p\300T*", <incomplete sequence \365>, tgtsize=tgtsize@entry=0x7ffca76e8d3c, tgt=tgt@entry=0x12ad3d75 "ZL\b u", irep=irep@entry=0x7ffca76e8d38, compressionAlgorithm=ROOT::RCompressionSetting::EAlgorithm::kZLIB) at /cvmfs/nica.jinr.ru/sw/SOURCES/ROOT/v6.26.10/v6-26-10/core/zip/src/RZip.cxx:79
No locals.

Сейчас запустил тот же самый пакет из 10 задач на другом компе, с точно такой же системой, но более мощным железом, и поставил при нем ИБП для надежности. Интересно чем кончится - если это ошибка приложения, то должно закончится одинаково: 9 нормально, а одна подвиснет навсегда.

В кадре #12 в _int_malloc() случился сегфолт. Ты установил обработчик SIGSEGV, он был вызван в кадре #10. Обработчик сигнала сам вызвал malloc(), который в свою очередь попытался взять мьютекс хипа. Но мьютекс хипа уже взят в кадре #13. Мьютекс хипа видимо нерекурсивный, поэтому дедлок.

Не надо вызывать malloc() (и библиотечные функции вообще) из обработчика сигнала. Обработчик сигнала может быть вызван в произвольный момент, состояние библиотечных мьютексов может быть любым, библиотечные функции из-за этого становятся нереентерабельны. Вот что можно вызывать из обработчика сигнала: https://man7.org/linux/man-pages/man7/signal-safety.7.html

Первопричина сегфолта в malloc() неизвестна. Обычно такое бывает при повреждении хипа. Обычно при таких ошибках рекомендуют собрать своё приложение с address sanitizer (gcc -fsanitize=address -static-libasan). Или прогнать под valgrind memcheck. Но для многочасовых считалок valgrind не подходит, слишком медленный.

Большое спасибо, «непонятно, но здорово!».
Дело в том, что это не я, я же специально у себя ушел от динамического выделения памяти в цикле, типа, «от греха подальше». Думаю, это на уровне компилятора gcc, даже не уровне Церновских создателей Root’a - основного инструмента обработки физического эксперимента (библиотек всяких на 15 гигов) , чем я и пользуюсь, иначе просто бы была тривиальная «утечка памяти». Дождусь результата на втором компе, потом информирую системную группу. Но боюсь, что людей мало, и они настолько заняты глобальными проблемами framework’a, и просто у них не будет времени разбираться в проблеме.

Повреждение хипа это не тривиальная утечка памяти, это обычно use after free. У приложения остался указатель на память, которую уже освободили, и приложение эту память модифицирует. Менеджер хипа хранит в освобождённой памяти свои структуры (free list), а приложение их случайно модифицирует, например, портит указатель на следующий узел free list-а. При очередном вызове malloc() менеджер хипа идёт по free list-у, берёт испорченный указатель на следующий узел, дереференсит его и ловит сегфолт, потому что испорченный указатель указывает за пределы адресного пространства процесса.

это обычно use after free

эту фразу хочется перевести как «это известный баг».
Пытаюсь осознать Ваши комментарии, и напрашивается вывод, что это все-таки не «битая память», а скорее всего нестыковки в временной диаграмме действий алгоритма управления процессами, нет в нем «предохранителя» от порчи хипа, да и как-то неэтично отправлять процесс в вечный сон, не считая это ошибкой чего-то, тем более, далее не следя за этим процессом.
Пакет задач, запущенный на другом компе завершился удачно - все 10 закончились без проблем, что говорит о принципиальной работоспособности кода на уровне C++, на котором он создан. Думаю, этот результат подтверждает интуитивные мысли, высказанные в предыдущем абзаце.

У вас два бага в приложении: порча хипа, приводящая к сегфолту в malloc, и плохой обработчик сигнала SIGSEGV, приводящий к дедлоку. Но виновато по вашему мнению не приложение, а все вокруг. Ядро виновато в том, что не распознало дедлок и отправило процесс в бесконечную спячку. Glibc виновата в том, что не распознала повреждение хипа и сегфолтнулось. Хотя это именно приложение нарушило контракты — сделало use after free, вызвало нереентерабельную функцию malloc из обработчика сигнала.

Что вы можете сделать как разработчик приложения? Можете сбросить обработчик сигнала SIGSEGV в SIG_DFL после инициализации библиотеки, чтобы ликвидировать баг с дедлоком. Можете собрать приложение с санитайзером, чтобы при следующем воспроизведении бага с use after free поймать его вовремя.

Если хотите исправлять приложение, а не обвинять всё вокруг.

Хорошо, раз я запускаю приложение, то я за него отвечаю. Если исходить из такой логики, то да, виноват сам: дотронулся - отвечаешь. Вопрос уровня, на котором должны обрабатываться вышеуказанные сигналы, в таком подходе не стоит, но остается вопрос:

ничтожно малая вероятность «порчи хипа» и точная причина этого.

Почему этот «баг» проявляется так редко, не чаще раза на 10^8 обменов с диском да и не на каждом компьютере?

По логике приложения выделение памяти нужно только для передачи данных с диска для их обработки, да и я не вдаюсь в процесс чтения этих данных - это стандартный метод, используемый не один десяток лет физиками всего мира. Не может быть так, что этот баг проявился только сейчас.
Поймите, я только хочу для себя, сопоставляя ВСЕ данные, логически понять, что произошло, на каком уровне эта нестыковка, и где граница между ОС и компилятором?
А Вам еще раз спасибо за КОНКРЕТНЫЙ разбор ситуации, а не общие слова, что память портится и у программиста «есть вся документация», чтобы не делать ошибок.

Почему этот «баг» проявляется так редко, не чаще раза на 10^8 обменов с диском да и не на каждом компьютере?

Потому что в коде программы используется либо неинициализированная память, либо память after free. Из-за этого набор байтов в этом куске памяти случаен и все последующие действия программы тоже случайны.

Данным, которые выводит программа, использующая случайный набор чисел в памяти нельзя доверять.

Программист с 50 летним стажем должен был это знать.