LINUX.ORG.RU
ФорумAdmin

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

 , ,


2

4

Дано:

система ubuntu-20.04

железо: AMD FX(tm)-6300 Six-Core Processor,
M5A78L-M LE/USB3(bios - v5.02)

решил использовать этот комп для расчетов. Запустил 6 абсолютно одинаковых задачек моделирования чего-то. Разница только в начальном случайном числе.

вот, что показывает top:

Tasks: 239 total,   6 running, 233 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,0 us,  0,6 sy, 82,9 ni, 16,5 id,  0,1 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :   7680,0 total,    362,2 free,   5360,9 used,   1956,9 buff/cache
MiB Swap:   8192,0 total,   7838,0 free,    354,0 used.   1999,8 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND  
   3928 xxx       30  10 1099912 363192  22576 R 100,0   4,6   1164:37 root.exe 
   3923 xxx       30  10 1662268 404528   3640 R  99,7   5,1   1163:23 root.exe 
   3924 xxx       30  10 1636572 458604   6800 R  99,7   5,8   1164:09 root.exe 
   3927 xxx       30  10 1138156 375096   3628 R  99,7   4,8   1163:01 root.exe 
   3925 xxx       30  10   14,2g   3,3g   6672 R  94,4  43,6   1163:07 root.exe 

после 10ти часов счета отвалилась одна задача, как будто, ее убили kill’ом, и что-то стало происходить с распределением памяти для оставшихся процессов. Причем, подобное на этом компьютере случается не в первый раз.

На 3х других компах (2 Ryzen и AMD Phenom(tm) II X4) с абсолютно той же ОС такие фортели не наблюдаются задачи досчитываются с одинаковыми ресурсами используемой памяти до конца. Например, на AMD Phenom(tm):

 top - 11:25:18 up 20:07,  1 user,  load average: 4,03, 4,03, 4,00
Tasks: 209 total,   5 running, 204 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,2 us,  1,2 sy, 98,5 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,2 si,  0,0 st
MiB Mem :   7937,5 total,    924,3 free,   2208,4 used,   4804,8 buff/cache
MiB Swap:   8192,0 total,   8192,0 free,      0,0 used.   5428,3 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND  
   3470 xxx       30  10  890304 399592  16428 R  99,7   4,9   1172:04 root.exe 
   3473 xxx       30  10  890600 393624  16664 R  99,7   4,8   1172:24 root.exe 
   3471 xxx       30  10  898620 436972  14196 R  98,7   5,4   1173:05 root.exe 
   3472 xxx       30  10  890064 393388  16756 R  98,3   4,8   1172:41 root.exe 

Вопрос: это железо или софт?

P.S.dmesg кроме warning о ACPI (на который иностранный народ советует забить, если присутствуют lm-sensors, а они есть

Перемещено hobbit из general



Последнее исправление: hobbit (всего исправлений: 3)
Ответ на: комментарий от PPP328

Для чего Вы написали эти ни на чем не обоснованные выводы? Все, что можно почерпнуть из вашего комментария: я полуграмотный программист. Полегчало? - «Мелко, Хоботов!»(с)

valentin630
() автор топика
Ответ на: комментарий от valentin630

ни на чем не обоснованные выводы?

Ну не знаю, может я за 11 лет коммерческого программирования немного сообразил разузнать что такое битая куча,как она появляется и как работает выделение и и освобождение памяти на стеке и хипе?

Все, что можно почерпнуть из вашего комментария: я полуграмотный программист.

И это тоже. Но раз вы не хотите читать вторую часть я продолжу наблюдение. Тут забавно как в зоопарке. Все вокруг виноваты кроме вашей программы. И компьютер и Церн и Gigabyte.

PPP328 ★★★★★
()
Ответ на: комментарий от valentin630

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

А в процессе обработки ничего не выделяется что ли?

Вообще, если код не конфиденциальный и нет каких-то опасений за что-то, то может выложите на обсуждение?

Поймите, я только хочу для себя, сопоставляя ВСЕ данные, логически понять, что произошло, на каком уровне эта нестыковка, и где граница между ОС и компилятором?

К сожалению мы тут на 90% гаданием на кофейной гуще занимаемся. Вывод кодов ошибок хотя бы позволил понять что это не OOM Killer прибивает, а какие-то проблемы внутри программы. Из-за чего конкретно - я бы даже все-равно аппаратной неисправности не исключал.

Есть смысл все-таки через инструменты проверки корректности работы типа Valgrind https://ru.wikipedia.org/wiki/Valgrind пропустить программу со всеми библиотеками. Полностью до падения через сутки оно не отработает, вернее слишком долго дожидаться будет, но может быть чего сразу выявит.

praseodim ★★★★★
()
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от praseodim

К сожалению мы тут на 90% гаданием на кофейной гуще занимаемся.

Я, может быть, что-то упускаю, но господин @iliyap уже всё по полочкам разобрал (есть же терпение у людей). Насколько это ТС поможет - не знаю. Захочет - разберётся.

bugfixer ★★★★★
()
Ответ на: комментарий от praseodim

А в процессе обработки ничего не выделяется что ли?

Конечный код компилируется из моей макры плюс оболочка framework c нужными библиотеками, скомпилированными заранее. Вся «кухня» framework’а занимает у меня порядка 15 Гигов. Я могу говорить только за себя, т.е. что я запрашиваю сам. Один раз я отвожу память (new) своим 3м классам, далее в цикле только инициализирую их различными параметрами через соответствующий метод и работаю с ними, используя «стандартные» методы framework’а, которым я сам никакой памяти не выделяю. Лично мой код - это порядка 10000 строчек, поэтому смысла приводить его не вижу, да и это не коммерческий облагороженный код, и все комментарии личного характера.
Единственное место, где может запрашиваться память - это в стандартных (используется метод framework’а для чтения структурированных данных с диска типа «framework->get()») операциях ввода данных. Но подозревать тут какой-то подвох не вижу оснований.
Абсолютно исключать «железо», конечно, преждевременно, но, если я правильно понял, то «повреждение хипа» не носит характер сбоя памяти. Но, на всякий случай, я еще раз запустил тот же самый пакет из 10 задач (отличие в них только первоначальным зерном датчика случайных чисел, но сами зерна те же, что и раньше) на «проблемном» компе, на котором, кстати, никогда система не подвешивалась.

valentin630
() автор топика
Ответ на: комментарий от bugfixer

господин @iliyap уже всё по полочкам разобрал

Я, может быть тоже чего-то не догоняю, но мне представляется, что он разобрал то, что предоставил gdb, но ответ почему это так произошло носит, все-таки, вероятностный характер, т.е. это одна из возможных причин, которая в какой-то степени исключается фактом непостоянности явления, я бы даже сказал сильнее - уникальностью такого события и случайностью появления.

valentin630
() автор топика
Ответ на: комментарий от valentin630

но мне представляется, что он разобрал то, что предоставил gdb

А что ещё нужно?

все-таки, вероятностный характер

Ну да - или встретишь динозавра, или нет. 50/50.

случайностью появления

Welcome to the real world, world of race conditions.

Единственное место, где может запрашиваться память

Эвона как. Любой string - это уже malloc (господам что прибегут рассказывать про SSO - мы в курсе, оставим за скобками).

PS. Оно должно было упасть по segfault’у (первопричина - разбираться нужно с этим), но не упало потому как зависло в обработчике сигналов (ну, ручки у кого-то кривые, что ж поделать).

PPS. Я понимаю Ваш background и менталитет, но никто здесь не будет выслушивать до конца «плач Ярославны». Куда копать - Вам уже показали, как по мне - так более чем конкретно. Дальше сами. Или в раздел Job.

bugfixer ★★★★★
()
Ответ на: комментарий от valentin630

На самом деле никаких «границ» внутри процесса нет. Процесс это одно плоское адресное пространство, структуры данных в этом адресном пространстве никак не защищены от порчи кодом, исполняющемся в адресном пространстве. А кода в адресном пространстве много – это и код приложения и код всех используемых им библиотек.

Есть лишь граница между процессом и ядром. Процесс не может испортить память ядра.

«Системный вызов read читает данные из файла в память процесса и не может портить структуры данных хипа» – такой подход наивен. Конечно может. Передаёшь в системный вызов read указатель на освобождённую память и системный вызов read затирает узел freelist-а мусором из файла. Потому что освобождённая память это не обязательно дырка в адресном пространстве процесса. Это память под управлением менеджера хипа. Но менеджер хипа реализован в юзерспейсе, и ядро о нём ничего не знает.

С примитивами синхронизации сложнее. Многие примитивы синхронизации в линуксе реализованы в юзерспейсе в glibc через системный вызов futex. Ядро при исполнении системного вызова futex не знает, какой примитив синхронизации позвал этот системный вызов, поэтому не всегда может достоверно распознать дедлок.

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

iliyap ★★★★★
()
Ответ на: комментарий от bugfixer

Делаю ставку на битую память.

Не обязательно. Любой админ в логах своих серверов видит раз в какое-то время (раз в какое - зависит от серверов и объёма памяти) срабатывание ECC. На системах без ECC пользователь не видит ничего, просто подземный стук, подобный стуку у ТС.

https://web.archive.org/web/20110819185612/http://lambda-diode.com/opinion/ec...

https://web.archive.org/web/20121027225744/http://lambda-diode.com/opinion/ec...

Dimez ★★★★★
()
Ответ на: комментарий от Dimez

подобный стуку у ТС

Чтобы подземный стук был так же часто, как у ТС, источник радиации надо прямо в корпус машины поместить. Хотя может, так и есть. Этот товарищ не перестает удивлять меня своим умом и сообразительностью.

rupert ★★★★★
()
Ответ на: комментарий от iliyap

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

Повторил расчеты того же самого пакета из 10 задач на «проблемном» компе и на более сильном железе. И там и там все завершилось через сутки без ошибок с одинаковыми результатами.

По крайней мере, можно снять вопрос с ошибками в программе - это либо железо, либо «угловой портфель».

valentin630
() автор топика