Кто подскажет, как ловить такие ошибки, как на рисунке?
Сразу предупреждаю - программа сделала всё, что должна была сделать. Такая штука украшает экран при завершении программы. В коде можно комментировать всё что угодно, ничего при выходе не меняется.
Ловля ошибок
Модератор: Модераторы
Ловля ошибок
У вас нет необходимых прав для просмотра вложений в этом сообщении.
программа секретная?
выкладывай код, мы никому. могила!
Добавлено спустя 1 минуту 16 секунд:
собрана с отладочной инфой? fpc собери с отладочной инфой
Добавлено спустя 1 минуту 24 секунды:
..mp.. = мультипоточность?
выкладывай код, мы никому. могила!
Добавлено спустя 1 минуту 16 секунд:
собрана с отладочной инфой? fpc собери с отладочной инфой
Добавлено спустя 1 минуту 24 секунды:
..mp.. = мультипоточность?
Повреждение памяти (скорее всего), т. е. запись за границами выделенного или двойное/неверное освобождение, heaptrc такое (иногда) детектит. Ещё можно попробовать директиву $CHECKPOINTERS, но если ты используешь указатели не только для динамической памяти, она неюзабельна в форме «включена на весь проект» из-за ложных срабатываний, придётся включать-выключать локально — вокруг отдельных методов или выражений.
zub
Да нет, программа не секретная, но к ней надо скачивать ещё несколько зависимостей.
https://github.com/VadimAnIsaev/GNU-MPFR-for-FreePascal
В разделе examples, файл называется pi_bel_mpfr.pas.
В принципе я знаю, где ошибка - она не у меня, а у разработчиков библиотеки. Правда они сами её ошибкой не считают.
У них там есть специальная инструкция, как выделять память для нескольких ихних переменных, а потом как правильно их утилизировать, чтобы подобных персидских ковров не возникало. Мне просто интересно, как такую ошибку вообще, в принципе отлавливать...
Инструкция к генерации ошибки:
- в коде программы нужно удалить (или закомментировать) все буквосочетания ", mpfr_ptr(0)", откомпилировать и любоваться на эту ошибку.
Нет, код без отладочной инфы. Кстати, вопрос - а отладочная инфа в моём коде поможет, если ошибка не в моём коде?
Ну что же Вы меня на ночь глядя так пугаете?! Ни в коем случае! Один разъединственный поток!
Добавлено спустя 2 минуты 31 секунду:
Спасибо, попробую...
Добавлено спустя 3 минуты 4 секунды:
Нет, поправка. Если в коде закомментировать так:
ошибка пропадает. Но ясности это не вносит...
Да нет, программа не секретная, но к ней надо скачивать ещё несколько зависимостей.
https://github.com/VadimAnIsaev/GNU-MPFR-for-FreePascal
В разделе examples, файл называется pi_bel_mpfr.pas.
В принципе я знаю, где ошибка - она не у меня, а у разработчиков библиотеки. Правда они сами её ошибкой не считают.
У них там есть специальная инструкция, как выделять память для нескольких ихних переменных, а потом как правильно их утилизировать, чтобы подобных персидских ковров не возникало. Мне просто интересно, как такую ошибку вообще, в принципе отлавливать...Инструкция к генерации ошибки:
- в коде программы нужно удалить (или закомментировать) все буквосочетания ", mpfr_ptr(0)", откомпилировать и любоваться на эту ошибку.
zub писал(а):собрана с отладочной инфой? fpc собери с отладочной инфой
Нет, код без отладочной инфы. Кстати, вопрос - а отладочная инфа в моём коде поможет, если ошибка не в моём коде?
zub писал(а):..mp.. = мультипоточность?
Ну что же Вы меня на ночь глядя так пугаете?! Ни в коем случае! Один разъединственный поток!
Добавлено спустя 2 минуты 31 секунду:
runewalsh писал(а):Ещё можно попробовать директиву $CHECKPOINTERS,
Спасибо, попробую...
Добавлено спустя 3 минуты 4 секунды:
Vadim писал(а):В коде можно комментировать всё что угодно, ничего при выходе не меняется.
Нет, поправка. Если в коде закомментировать так:
Код: Выделить всё
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 запускать пробовали?
Дож писал(а):Курку из gdb запускать пробовали?
А это как?
>>- в коде программы нужно удалить (или закомментировать) все буквосочетания ", mpfr_ptr(0)", откомпилировать и любоваться на эту ошибку.
И вы это считаете не ошибкой в вашем коде и ошибкой у разрабов либы? mpfr_clears явно с переменным числом параметров, а нолик подается как маркер конца - без него либа очищает невыделенную память
>> У них там есть специальная инструкция, как выделять память для нескольких ихних переменных, а потом как правильно их утилизировать, чтобы подобных персидских ковров не возникало.
Разрабы они такие, хош-нихошь придется по ихнему плясать
Добавлено спустя 7 минут 42 секунды:
>>Нет, код без отладочной инфы. Кстати, вопрос - а отладочная инфа в моём коде поможет, если ошибка не в моём коде?
Увидишь последнюю свою строчку перед ошибкой. Пакет с отладочной инфой либы поможет увидеть место возникновения ошибки в либе и сваять багрепорт если ошиюка на стороне либы.
Однако в самых интересных случаях место возникновения ошибки и место приводящее к ее возникновению - совершенно разные места))
Как и в данном случае вылет в либе внутри mpfr_clears, а проблема в отсутствии маркера конца последовательности освобождаемых "переменных" либы
И вы это считаете не ошибкой в вашем коде и ошибкой у разрабов либы? mpfr_clears явно с переменным числом параметров, а нолик подается как маркер конца - без него либа очищает невыделенную память
>> У них там есть специальная инструкция, как выделять память для нескольких ихних переменных, а потом как правильно их утилизировать, чтобы подобных персидских ковров не возникало.
Разрабы они такие, хош-нихошь придется по ихнему плясать
Добавлено спустя 7 минут 42 секунды:
>>Нет, код без отладочной инфы. Кстати, вопрос - а отладочная инфа в моём коде поможет, если ошибка не в моём коде?
Увидишь последнюю свою строчку перед ошибкой. Пакет с отладочной инфой либы поможет увидеть место возникновения ошибки в либе и сваять багрепорт если ошиюка на стороне либы.
Однако в самых интересных случаях место возникновения ошибки и место приводящее к ее возникновению - совершенно разные места))
Как и в данном случае вылет в либе внутри mpfr_clears, а проблема в отсутствии маркера конца последовательности освобождаемых "переменных" либы
zub писал(а):И вы это считаете не ошибкой в вашем коде и ошибкой у разрабов либы? mpfr_clears явно с переменным числом параметров, а нолик подается как маркер конца - без него либа очищает невыделенную память
Я бы с этим согласился, если бы ошибка выскакивала всегда. Но она непрогнозируема. Без нолика в конце, в одной программе есть ошибка, а в другой, работающей подобным образом, её нету. Или вот вопрос из той же серии: сишная функция printf() работает с таким же списком параметров с неопределённым числом, однако там ноль в конце ставить не требуется...
Я опечатался, хотел написать "корку".
Имею в виду coredump (в логе написано "Слепок снят", так что я предполагаю, что при падении куда-то сохранился coredump, местоположение зависит от ОС).
Имею в виду coredump (в логе написано "Слепок снят", так что я предполагаю, что при падении куда-то сохранился coredump, местоположение зависит от ОС).
Дож писал(а):Я опечатался, хотел написать "корку".
А, понятно...
Дож писал(а):в логе написано "Слепок снят", так что я предполагаю, что при падении куда-то сохранился coredump, местоположение зависит от ОС
Да вообще-то при работе через DBG он пишет, куда куда скидывает этот самый coredump, но в том месте почему-то ничего не обнаруживается...
Возможно, что прав нет на запись в соответствующую директорию у процесса, либо размер корки превышает допустимый лимит.
В принципе, корка даст ту же информацию, что и процесс, запущенный из gdb и упавший, но она может пригодиться, если из gdb прога не падает или нет возможности поймать момент падения (сценарий "падает боевой сервер раз в сутки").
По всем признакам, вы не соблюдаете конвенцию вызова mpfr_clears
https://www.mpfr.org/mpfr-current/mpfr. ... -Interface
В принципе, корка даст ту же информацию, что и процесс, запущенный из 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).
Дож писал(а):По всем признакам, вы не соблюдаете конвенцию вызова mpfr_clears
Ну, в общем, да. Я об этом догадался довольно быстро.
Просто мне интересно, как по подобным паническим сообщениям отыскивать причину, если совершенно не знаешь куда копать. Согласитесь, в этом случае программисту должен помочь компилятор своими сообщениями. Однако, увы, это уже сишный уровень, мать его за ногу, который как раз большой мастер запуть любую простую вешь...
Вдобавок, покопавшись в исходниках, я увидел, что у этой функции может быть и такой формат:
Код: Выделить всё
mpfr_clears(Количество_параметров, список_параметров)что разрабы в инструкции указать не потрудились. Мне такой вариант больше нравится, я его сейчас испытываю, чтобы понять, не ошибся ли я. И если не ошибся, то у разрабов тут ошибка - первый параметр должен быть целочисленный. Хотя, с точки зрения применения нолика как конца списка, всё правильно. Другое дело, что эта функция изначально предполагалась с бОльшим, чем 1 или 2 числом убиваемых переменных, поэтому второй вариант логичнее.
Просто мне интересно, как по подобным паническим сообщениям отыскивать причину, если совершенно не знаешь куда копать.
Смотреть корку.
Согласитесь, в этом случае программисту должен помочь компилятор своими сообщениями.
Не соглашусь.
>>Смотреть корку.
а что там будет такого чего нет на скриншоте в нульпосте?
а что там будет такого чего нет на скриншоте в нульпосте?
Аргумент функции free и память вокруг