Есть ли известная проблема с генерацией исключений в g ++ с Purify, вызывающая SIGABRT? - PullRequest
1 голос
/ 02 февраля 2011

На самом деле мой настоящий вопрос: есть ли что-то не так с указанной строкой в ​​следующем коде («Причины SIGABRT»):

char* myFunc(char *param) {
  char* leaked = new char[80]; // Intentionally leaked
  if (param == NULL) throw logic_error("Parameter was null!"); // Causes SIGABRT
  strcpy(leaked, param);
  // Missing return, but never gets this far, so should be okay.
}

void test_non_happy_myFunc()
{
  try {
    myFunc(NULL);
  } catch (logic_error&) {
    cout << "Test succeeded!" << endl;
    return;
  }

  cout << "Test FAILED!" << endl;
}

int main()
{
  test_non_happy_myFunc();
}

Я пытаюсь создать минимальный контрольный пример для отправки в IBM / Rational, чтобы доказать, что существует проблема с их программным обеспечением для очистки, поэтому я запускаю его в S.O. сообщество первым. Да, умышленно происходит утечка памяти во 2-й строке, и да, я знаю, что указатель «утечка» унифицируется при возникновении исключения.

Приведенный выше код обычно выполняется за пределами cleany при компиляции с g ++, но вызывает дамп ядра при запуске внутри cleany. Я сделал ошибку новичка в приведенном выше коде (сделав SIGABRT моей ошибкой), или я могу указать пальцем на IBM / Rational Purify?

Редактировать: (уточнения)

Запустите из командной строки без очистки, вышеприведенная полная программа напечатает:

Test succeeded!

Беги внутрь очищения, очищай отчеты:

COR: Fatal core dump
This is occurring while in thread 1299:
        _p450static    [rtlib.o]
        abort          [libc.so.6]
        uw_init_context_1 [unwind-dw2.c:1256]
        _Unwind_RaiseException [unwind.inc:88]
        __cxa_throw    [eh_throw.cc:78]
        myFunc(char*)  [exception_test.cc:9]
        test_non_happy_myFunc() [exception_test.cc:17]
        main           [exception_test.cc:28]

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

1 Ответ

1 голос
/ 02 февраля 2011

За исключением отсутствующего оператора return в myFunc, я не вижу ничего плохого в приведенном выше коде. Однако перед тем, как возложить вину на код других (особенно широко используемый код), я бы дважды проверил, что ничего плохого не произошло ДО этого (как вы знаете, если что-то вызвало демонов UB, то миллион выполненных инструкций назад все еще возможен, что только теперь будет видимые эффекты).

Только если компиляция только показанного кода с main просто вызывает test_non_happy_myFunc и без таких причудливых вещей, как пользовательские глобальные распределители, по-прежнему выявляет проблему, тогда я перенесу поиск в ваши инструменты (т.е. чистоту, компилятор и т. Д.), И я не остановлюсь, пока не буду на 100% уверен, что проблема в этом.

...