История изменений

Однако этого не происходит, потому что сечение взаимодействия мюона с веществом мало.

Настолько ли мало, чтобы совсем не опасаться? К тому же там не только мюоны. В любом случае это явление учитывается, в 2020-м году даже международный стандарт на оборудование связи вышел New ITU standards to prevent soft errors caused by cosmic rays https://www.itu.int/hub/2020/05/new-itu-standards-to-prevent-soft-errors-caus...

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

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

Здесь на английском довольно подробно про OOM Killer и журналирование событий https://www.baeldung.com/linux/which-process-killed

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

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

Дело было в том, что две линейки памяти не хотели вместе работать на этой материнке гигабайтовской, а на другой, не гигабайтовской с другим чипом работали! Недавно освежал БИОС, увидел, что были у фирмы улучшения по совместимости памяти.

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

Однако этого не происходит, потому что сечение взаимодействия мюона с веществом мало.

Настолько ли мало, чтобы совсем не опасаться? К тому же там не только мюоны. В любом случае это явление учитывается, в 2020-м году даже международный стандарт на оборудование связи вышел New ITU standards to prevent soft errors caused by cosmic rays https://www.itu.int/hub/2020/05/new-itu-standards-to-prevent-soft-errors-caus...

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

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

Здесь на английском довольно подробно про OOM Killer и журналирование событий https://www.baeldung.com/linux/which-process-killed

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

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