Сбой приложения C ++, включая ada dll, не создает дамп ядра

Теперь, почти 2 года спустя (все еще работая в той же компании, что и Кристофер, когда он задал вопрос), вопрос был поднят снова - и, наконец, я думаю, что понимаю, почему не создается дамп ядра !!

Проблема вызвана средой выполнения Ada, которая по умолчанию реализует обработчик сигналов для некоторых сигналов POSIX (для Linux: SIGABRT, SIGFPE, SIGILL, SIGSEGV и SIGBUS). Для GNAT / linux обработчик сигнала называется __gnat_error_handler в a-init.c, что выглядит примерно так:

static void
__gnat_error_handler (int sig)
{
  struct Exception_Data *exception;
  char *msg;
  static int recurse = 0;
  ...
  switch (sig)
    {
    case SIGSEGV:

      if (recurse)
      {
        exception = &constraint_error;
        msg = "SIGSEGV";
      }
      else
      {
        ...
        msg = "stack overflow (or erroneous memory access)";
        exception = &storage_error;
      }
      break;
     }
    recurse = 0;
    Raise_From_Signal_Handler (exception, msg);
 }

Этот обработчик является «широким процессом» и будет вызываться любым инициированным сигналом, независимо от того, из какой части процесса он исходит (независимо от того, закодирован ли он на Ada / C / C ++ ...).

При вызове обработчик вызывает исключение Ada и оставляет его среде выполнения Ada для поиска подходящего обработчика исключений - если такой обработчик не найден (например, когда SIGSEGV генерируется какой-либо частью кода C ++), Ada -runtime возвращается, чтобы просто завершить процесс и оставить простую распечатку из __gnat_error_handler (например, «переполнение стека (или ошибочный доступ к памяти)»).

http://www2.adacore.com/gap-static/GNAT_Book/html/node25.htm

Чтобы предотвратить обработку POSIX-сигнала во время выполнения Ada и преобразовать его в исключение Ada, можно отключить поведение по умолчанию, используя

pragma Interrupt_State (Name => value, State => SYSTEM | RUNTIME | USER);,

например. чтобы отключить обработку SIGSEGV, определите

Pragma Interrupt_State(SIGSEGV, SYSTEM);

в вашем Ada-коде - теперь поведение системы по умолчанию будет запускаться при подаче сигнала SIGSEGV, и будет сгенерирован дамп ядра, который позволит вам отследить источник проблемы!

Я думаю, что это довольно важная проблема, о которой следует помнить при смешивании Ada и C / C ++ на * NIX-платформах, поскольку это может ввести вас в заблуждение, что проблемы происходят из кода Ada (поскольку распечатка указывает на исключение, сгенерированное из Ada ), когда реальный источник проблемы лежит в C / C ++ - коде ...

Хотя, вероятно, безопасно отключить обработку SIGSEGV по умолчанию в среде выполнения Ada (я думаю, что ни один здравомыслящий программист не использует это в любой «ожидаемой» обработке ошибок ... Ну, может быть, используется в авиационном программном обеспечении или подобном, когда какое-то «последнее средство» "функциональность должна поддерживаться, чтобы избежать чего-то действительно плохого ...) Я думаю, следует проявить некоторую осторожность, а затем" переопределить "обработку сигналов в среде выполнения Ada.

Одной из проблем может быть сигнал SIGFPE, который также по умолчанию вызывает исключение Ada Constraint_Error. Этот тип исключения может использоваться Ada-кодом как «ожидаемое поведение». Отключение SIGFPE с помощью Pragma Interrupt_State может серьезно повлиять на выполнение Ada-кода и привести к сбою вашего приложения в «нормальных обстоятельствах» - с другой стороны, любое деление на ноль в C / C ++ - коде запустит механизм обработки исключений Ada, и оставим вас без каких-либо реальных следов происхождения проблемы ...

Мне это кажется действительно хорошим использованием вашей AdaCore поддержки. Вы не обязаны найти много людей вне этой компании, которые хорошо знакомы с последствиями взаимодействия между средой выполнения Gnu Ada и C ++.

Я бы посоветовал вам для отладки кода Ada добавить последний обработчик исключений для всего, что, в свою очередь, сбрасывает стек исключений. У большинства поставщиков есть способы сделать это, обычно на основе Ada.Exceptions.Exception_Information и Ada.Exceptions.Exception_Message.

Я нашел обсуждение в перспектива безопасности (поиск вредоносных программ). В основном есть 10 сигналов, которые вы можете попробовать, SIGSEGV - только один из них.

Кажется, вы можете просто вызвать sigaction(SIGSEGV, 0, SIG_DFL);, чтобы восстановить поведение сигнала по умолчанию.