Ловля ошибок

[Vadim]

Кто подскажет, как ловить такие ошибки, как на рисунке?
Сразу предупреждаю - программа сделала всё, что должна была сделать. Такая штука украшает экран при завершении программы. В коде можно комментировать всё что угодно, ничего при выходе не меняется.

[zub]

программа секретная?
выкладывай код, мы никому. могила!

Добавлено спустя 1 минуту 16 секунд:
собрана с отладочной инфой? fpc собери с отладочной инфой

Добавлено спустя 1 минуту 24 секунды:
..mp.. = мультипоточность?

[runewalsh]

Повреждение памяти (скорее всего), т. е. запись за границами выделенного или двойное/неверное освобождение, heaptrc такое (иногда) детектит. Ещё можно попробовать директиву $CHECKPOINTERS, но если ты используешь указатели не только для динамической памяти, она неюзабельна в форме «включена на весь проект» из-за ложных срабатываний, придётся включать-выключать локально — вокруг отдельных методов или выражений.

[Vadim]

zub
Да нет, программа не секретная, но к ней надо скачивать ещё несколько зависимостей.
https://github.com/VadimAnIsaev/GNU-MPFR-for-FreePascal
В разделе examples, файл называется pi_bel_mpfr.pas.
В принципе я знаю, где ошибка - она не у меня, а у разработчиков библиотеки. Правда они сами её ошибкой не считают. У них там есть специальная инструкция, как выделять память для нескольких ихних переменных, а потом как правильно их утилизировать, чтобы подобных персидских ковров не возникало. Мне просто интересно, как такую ошибку вообще, в принципе отлавливать...
Инструкция к генерации ошибки:
- в коде программы нужно удалить (или закомментировать) все буквосочетания ", mpfr_ptr(0)", откомпилировать и любоваться на эту ошибку.

собрана с отладочной инфой? fpc собери с отладочной инфой

Нет, код без отладочной инфы. Кстати, вопрос - а отладочная инфа в моём коде поможет, если ошибка не в моём коде?

..mp.. = мультипоточность?

Ну что же Вы меня на ночь глядя так пугаете?! Ни в коем случае! Один разъединственный поток!

Добавлено спустя 2 минуты 31 секунду:

Ещё можно попробовать директиву $CHECKPOINTERS,

Спасибо, попробую...

Добавлено спустя 3 минуты 4 секунды:

В коде можно комментировать всё что угодно, ничего при выходе не меняется.

Нет, поправка. Если в коде закомментировать так:

Код: Выделить всё

mpfr_clears(@tmp_1, @tmp1, @tmp2, @tmp3, @tmp5{, @tmp7, @tmp9, mpfr_ptr(0)});
//  mpfr_clears(@m1, @m2, @m3, @m4, @m5, @m6, @m7, @m8, mpfr_ptr(0));
//  mpfr_clears(@t1, @t2, mpfr_ptr(0));

ошибка пропадает. Но ясности это не вносит...

[Дож]

Курку из gdb запускать пробовали?

[Vadim]

Курку из gdb запускать пробовали?

А это как?

[zub]

>>- в коде программы нужно удалить (или закомментировать) все буквосочетания ", mpfr_ptr(0)", откомпилировать и любоваться на эту ошибку.
И вы это считаете не ошибкой в вашем коде и ошибкой у разрабов либы? mpfr_clears явно с переменным числом параметров, а нолик подается как маркер конца - без него либа очищает невыделенную память

>> У них там есть специальная инструкция, как выделять память для нескольких ихних переменных, а потом как правильно их утилизировать, чтобы подобных персидских ковров не возникало.
Разрабы они такие, хош-нихошь придется по ихнему плясать

Добавлено спустя 7 минут 42 секунды:
>>Нет, код без отладочной инфы. Кстати, вопрос - а отладочная инфа в моём коде поможет, если ошибка не в моём коде?
Увидишь последнюю свою строчку перед ошибкой. Пакет с отладочной инфой либы поможет увидеть место возникновения ошибки в либе и сваять багрепорт если ошиюка на стороне либы.
Однако в самых интересных случаях место возникновения ошибки и место приводящее к ее возникновению - совершенно разные места))
Как и в данном случае вылет в либе внутри mpfr_clears, а проблема в отсутствии маркера конца последовательности освобождаемых "переменных" либы

[Vadim]

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

Я бы с этим согласился, если бы ошибка выскакивала всегда. Но она непрогнозируема. Без нолика в конце, в одной программе есть ошибка, а в другой, работающей подобным образом, её нету. Или вот вопрос из той же серии: сишная функция printf() работает с таким же списком параметров с неопределённым числом, однако там ноль в конце ставить не требуется...

[Дож]

Я опечатался, хотел написать "корку".

Имею в виду coredump (в логе написано "Слепок снят", так что я предполагаю, что при падении куда-то сохранился coredump, местоположение зависит от ОС).

[Vadim]

Я опечатался, хотел написать "корку".

А, понятно...

в логе написано "Слепок снят", так что я предполагаю, что при падении куда-то сохранился coredump, местоположение зависит от ОС

Да вообще-то при работе через DBG он пишет, куда куда скидывает этот самый coredump, но в том месте почему-то ничего не обнаруживается...

[Дож]

Возможно, что прав нет на запись в соответствующую директорию у процесса, либо размер корки превышает допустимый лимит.

В принципе, корка даст ту же информацию, что и процесс, запущенный из gdb и упавший, но она может пригодиться, если из gdb прога не падает или нет возможности поймать момент падения (сценарий "падает боевой сервер раз в сутки").

По всем признакам, вы не соблюдаете конвенцию вызова mpfr_clears
https://www.mpfr.org/mpfr-current/mpfr. ... -Interface

The va_list is assumed to be composed only of type mpfr_t (or equivalently mpfr_ptr). It begins from x, and ends when it encounters a null pointer (whose type must also be mpfr_ptr).

[Vadim]

По всем признакам, вы не соблюдаете конвенцию вызова mpfr_clears

Ну, в общем, да. Я об этом догадался довольно быстро.
Просто мне интересно, как по подобным паническим сообщениям отыскивать причину, если совершенно не знаешь куда копать. Согласитесь, в этом случае программисту должен помочь компилятор своими сообщениями. Однако, увы, это уже сишный уровень, мать его за ногу, который как раз большой мастер запуть любую простую вешь...
Вдобавок, покопавшись в исходниках, я увидел, что у этой функции может быть и такой формат:

Код: Выделить всё

mpfr_clears(Количество_параметров, список_параметров)

что разрабы в инструкции указать не потрудились. Мне такой вариант больше нравится, я его сейчас испытываю, чтобы понять, не ошибся ли я. И если не ошибся, то у разрабов тут ошибка - первый параметр должен быть целочисленный. Хотя, с точки зрения применения нолика как конца списка, всё правильно. Другое дело, что эта функция изначально предполагалась с бОльшим, чем 1 или 2 числом убиваемых переменных, поэтому второй вариант логичнее.

[Дож]

Просто мне интересно, как по подобным паническим сообщениям отыскивать причину, если совершенно не знаешь куда копать.

Смотреть корку.

Согласитесь, в этом случае программисту должен помочь компилятор своими сообщениями.

Не соглашусь.

[zub]

>>Смотреть корку.
а что там будет такого чего нет на скриншоте в нульпосте?

[Дож]

Аргумент функции free и память вокруг