Erlang: No Crash Dump

Question

Я бегу ejabberd, и каждый так часто он падает. Чтобы понять, почему он разбился, я знаю, что нужно посмотреть в файле erl_crash.dump. Проблема в том, что файл erl_crash.dump не выглядит. Однако есть файл дампа ядра. Загрузка его в БГД и работает «BT полные,» здесь являются две верхние рамы:

(gdb) bt full 
#0 0x000000000054df83 in prepare_crash_dump (secs=<optimized out>) at sys/unix/sys.c:735 
    max = <optimized out> 
    env = "\005", '\000' <repeats 15 times>"\200, \373!ڴ" 
    heart_port = 0x7fb46f31eab0 
    hp = 0x7fb4d6efb938 
    heart_fd = {865035, -1} 
    has_heart = 0 
    i = <optimized out> 
    envsz = <optimized out> 
    heap = {4460060, 140412855877120, 1} 
    list = 18446744073709551611 
#1 erts_sys_prepare_crash_dump (secs=<optimized out>) at sys/unix/sys.c:780 

Таким образом, оказывается, что он разбился, пока он пытался написать аварийный дамп, но не получил всю дорогу , Я провел некоторое исследование, и это звучит очень похоже на проблему, которая была опубликована ранее (https://groups.google.com/forum/#!msg/erlang-programming/XH2Uly6hsLY/aeR2Yx2UkZMJ). Сердце не было включено в командной строке, что означает, что это не должно быть проблемой, но ... в дампе ядра, heart_port устанавливается на что-то ненулевое. Это должно означать, что сердце где-то скрывается, не так ли? Если да, есть ли способ рассказать сердце действительно не работает?

Answer 1

Это сбой erlang VM, а не сбой процесса erlang, поэтому нет созданного erl_crash.dump. По моему опыту, я подозреваю, что это не ядро ​​в prepare_crash_dump, но у вас неправильная загрузка бинарных файлов в gdb. Если вы не отлаживаете систему, которая разбилась, вы должны скопировать двоичные файлы erlang и указать GDB.

Answer 2

В erts 8.0 у вас есть: убедитесь, что вы создали аварийный дамп при выходе из памяти. Это было случайно удалено в выпуске erts-7.3.

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