Вывод Valgrind с адресом и вопросительными знаками?
Я только что получил вывод от 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 раньше, и все результаты были такими, как описано в руководство. Я использовал эту команду valgrind:
valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --track-origins=yes
Сама программа выкрикивает ошибку сегментации. Хотя в этот раз valgrind не сообщает мне ни о каком месте утечки памяти, из отладки я определил место, где происходит ошибка сегментации. К сожалению, он находится в функции решателя ODE из библиотеки решателей Intel ODE (dodesol), и у меня нет к нему доступа. Я тщательно проверил все параметры, которые я передаю этой функции, много раз, и они кажутся нормальными (по крайней мере, соответствуют тем, которые приведены в руководстве и примерах, которые я имел ранее).
Решение
??? почти наверняка означает, что Вальгринд не смог найти символ где-либо рядом с адресом, о котором идет речь. Я подозреваю, что вы выполняете код там, где его нет. Это может быть результатом перезаписи адреса возврата в стеке, например, возможно, в результате переполнения буфера (но другие ошибки указателя могут вызвать его). Valgrind очень хорошо справляется с проблемами с динамически выделяемой памятью, но имеет больше трудная работа с локальными переменными, потому что не всегда возможно определить, где заканчивается массив в стеке.
Другие решения
Один из сценариев, в котором вы получите этот результат, — это если вы запускаете Valgrind в раздельном двоичном файле / библиотеке и обнаруживает ошибку в локальном символе (например, в статической функции).
Использование несвязанной версии двоичного файла / библиотеки, которая по-прежнему содержит информацию обо всех локальных символах, даст исходный файл и номер строки в выходных данных Valgrind.