Ответ 1

ПРЕДУПРЕЖДЕНИЕ - этот ответ содержит ряд предположений, основанных на неполной информации. Надеюсь, он по-прежнему полезен, хотя!

Почему появляется segfault?

Как показывает трассировка стека, ядро ​​занято созданием дампа ядра разбитого процесса.

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

Как указано в комментариях MM, результат выражения 1 < 31 равен undefined стандартами C, поэтому трудно сказать, какое фактическое значение передается malloc, но на основе последующее поведение я предполагаю, что это большое число.

Обратите внимание, что для успеха malloc вам не нужно, чтобы у вас было столько ОЗУ в вашей системе - ядро ​​расширит виртуальный размер вашего процесса, но фактическая RAM будет выделена только тогда, когда ваша программа действительно обратится к этой ОЗУ.

Я считаю, что вызов malloc преуспевает или, по крайней мере, возвращает, потому что вы заявляете, что он segfaults после нажатия кнопки enter, поэтому после вызова fgets.

В любом случае segfault приводит к ядру для выполнения дампа ядра. Если процесс имеет большой виртуальный размер, это может занять много времени, особенно если ядро ​​решает сбросить все страницы, даже те, которые никогда не затрагивались процессом. Я не уверен, что он это сделает, но если бы это произошло, и если в системе не хватило оперативной памяти, ему пришлось бы начать замену страниц в и из памяти, чтобы сбрасывать их на основной дамп. Это создаст высокую нагрузку ввода-вывода, которая может привести к тому, что процесс окажется невосприимчивым (и общая производительность системы будет снижена).

Возможно, вы сможете проверить некоторые из них, просмотрев каталог дампа abrtd (возможно /var/tmp/abrt или проверить /etc/abrt/abrt.conf), где вы можете найти основные дампы (или, возможно, частичные дампы ядра), которые были созданы.

Если вы можете воспроизвести поведение, вы можете проверить:

• /proc/[pid]/maps, чтобы увидеть карту адресного пространства процесса и посмотреть, действительно ли он большой
• Используйте инструмент, например vmstat, чтобы проверить, не меняется ли система, количество операций ввода-вывода и состояние ожидания IO Wait.
• Если вы выполняли sar, вы можете увидеть подобную информацию даже за период до перезапуска abrtd.

Почему создается дамп ядра, хотя ulimit -c равен 0?

В соответствии с этот отчет об ошибках, abrtd инициирует сбор дампа ядра независимо от настроек ulimit.

Почему это не запускалось снова, когда arbtd был запущен еще раз?

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

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

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

Также возможно, что обновление yum обновило abrtd, но не перезапустило его, так что при его перезапуске новая версия была запущена.