Выход Valgrind с адресами и вопросительными знаками?

Question

я только получить выход из Valgrind, что я не совсем понимаю:

==20290== Invalid read of size 1 
==20290== at 0x8C1D678: ??? 
==20290== by 0x5D74C47: ??? 
==20290== Address 0xee818c7d is not stack'd, malloc'd or (recently) free'd 
==20290== 
==20290== 
==20290== Process terminating with default action of signal 11 (SIGSEGV) 
==20290== Access not within mapped region at address 0xEE818C7D 
==20290== at 0x8C1D678: ??? 
==20290== by 0x5D74C47: ??? 
==20290== If you believe this happened as a result of a stack 
==20290== overflow in your program's main thread (unlikely but 
==20290== possible), you can try to increase the size of the 
==20290== main thread stack using the --main-stacksize= flag. 
==20290== The main thread stack size used in this run was 8388608. 
==20290== 

В частности, я смущен этими знаками вопроса. Обычно то, что вы получаете на этом месте, - это местоположение ошибок, обнаруженных valgrind. Я использовал valgrind раньше, и весь вывод был как описано в manual. Я использовал эту команду valgrind:

valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --track-origins=yes 

Сама программа кричит на ошибку сегментации. Хотя valgrind не говорит мне о месте утечки памяти на этот раз, от отладки я определил место, где возникает ошибка сегментации. К сожалению, он находится в функции решения ODE из библиотеки Intel ODE solver (dodesol), и у меня нет доступа к ней. Я тщательно проверил все параметры, которые я передаю этой функции много раз, и они кажутся нормально (по крайней мере, соответствуют тем, которые были в руководстве, и примерами, которые я имел раньше).

Answer 1

??? почти наверняка означает, что Valgrind не смог найти символ где-нибудь рядом с указанным адресом. Я подозреваю, что вы выполняете код, где нет кода. Это может быть результатом перезаписывания обратного адреса в стеке, например, возможно, в результате переполнения буфера (но другие ошибки указателя могут вызвать его). Valgrind очень хорош в проблемах с динамически распределенной памятью, но имеет больше сложная работа с локальными переменными, потому что не всегда возможно определить, где заканчивается массив на стеке.

Answer 2

Один сценарий, в котором вы получите этот результат, - это если вы используете Valgrind на разделенной бинарной/библиотеке и обнаруживаете ошибку в локальном символе (например, статической функции).

Использование неиспользуемой версии бинарной/библиотеки, которая все еще содержит информацию обо всех локальных символах, даст исходный файл и номер строки в выводе Valgrind.