Valgrind не показывает номера строк, несмотря на флаг -g (на Ubuntu 11.10/VirtualBox)
Я следую "Learn C the Hard Way", в частности в главе о Valgrind. В этой главе вы намеренно ошибаетесь, чтобы показать, как работает Valgrind.
Когда я запускаю упражнение под Valgrind, я не получаю номера строк в трассировке стека, просто "(ниже основного)" для ошибок.
Я определенно компилирую с флагом -g.
Выход My Valgrind выглядит следующим образом:
[email protected]:~/projects/Learning/C$ valgrind ./ex4
==5190== Memcheck, a memory error detector
==5190== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==5190== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==5190== Command: ./ex4
==5190==
==5190== Use of uninitialised value of size 4
==5190== at 0x4078B2B: _itoa_word (_itoa.c:195)
==5190== by 0x407CE55: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
==5190== Conditional jump or move depends on uninitialised value(s)
==5190== at 0x4078B33: _itoa_word (_itoa.c:195)
==5190== by 0x407CE55: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
==5190== Conditional jump or move depends on uninitialised value(s)
==5190== at 0x407CC10: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
==5190== Conditional jump or move depends on uninitialised value(s)
==5190== at 0x407C742: vfprintf (vfprintf.c:1619)
==5190== by 0x40831DE: printf (printf.c:35)
==5190== by 0x4052112: (below main) (libc-start.c:226)
==5190==
I am 0 years old.
I am 68882420 inches tall.
==5190==
==5190== HEAP SUMMARY:
==5190== in use at exit: 0 bytes in 0 blocks
==5190== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5190==
==5190== All heap blocks were freed -- no leaks are possible
==5190==
==5190== For counts of detected and suppressed errors, rerun with: -v
==5190== Use --track-origins=yes to see where uninitialised values come from
==5190== ERROR SUMMARY: 22 errors from 4 contexts (suppressed: 11 from 6)
Я использую Ubuntu 11.10 в виртуальной виртуальной машине.
Спасибо за любую помощь.
Обновление
Похоже, что если я вызываю функцию из main()
, и эта функция содержит ошибку (например, неинициализированную переменную), то я получаю трассировку к тому месту, где функция была вызвана в main()
. Однако ошибки внутри main()
остаются неопределенными. См. эту вставку для примера.
Ответы
Ответ 1
Результат, который вы предоставили в своем вопросе, содержит следующую строку:
==5190== Use --track-origins=yes to see where uninitialised values come from
За это сообщение вы должны запустить ./ex4
следующим образом:
valgrind --track-origins=yes ./ex4
Чтобы избежать некоторых проблем с тем, чтобы Valgrind не смог найти отладочную информацию, вы можете использовать статическое связывание:
gcc -static -g -o ex4 ex4.c
Выход Valgrind будет содержать сообщения типа Uninitialised value was created by a stack allocation
:
==17673== Memcheck, a memory error detector
==17673== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==17673== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==17673== Command: ./ex4
...
==17673== Use of uninitialised value of size 4
==17673== at 0x805CA7B: _itoa_word (in /home/user/ex4)
==17673== by 0x8049D5F: printf (in /home/user/ex4)
==17673== by 0x8048ECD: main (ex4.c:8)
==17673== Uninitialised value was created by a stack allocation
==17673== at 0x8048EFA: bad_function (ex4.c:17)
...
==17673== Use of uninitialised value of size 4
==17673== at 0x805CA7B: _itoa_word (in /home/user/ex4)
==17673== by 0x8049D5F: printf (in /home/user/ex4)
==17673== by 0x80490BE: (below main) (in /home/user/ex4)
==17673== Uninitialised value was created by a stack allocation
==17673== at 0x8048EBE: main (ex4.c:4)
...
I am -1094375076 years old.
...
I am -1094369310 inches tall.
...
==17673==
==17673== HEAP SUMMARY:
==17673== in use at exit: 0 bytes in 0 blocks
==17673== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==17673==
==17673== All heap blocks were freed -- no leaks are possible
==17673==
==17673== For counts of detected and suppressed errors, rerun with: -v
==17673== ERROR SUMMARY: 83 errors from 21 contexts (suppressed: 0 from 0)
Файл ex4.c
:
1 #include <stdio.h>
2
3 int main()
4 {
5 int age = 10;
6 int height;
7
8 bad_function();
9
10 printf("I am %d years old.\n");
11 printf("I am %d inches tall.\n", height);
12
13 return 0;
14 }
15
16 int bad_function()
17 {
18 int x;
19 printf("%d\n", x);
20 }
Выход Valgrind не идеален. Он идентифицирует фрейм (функцию) стека, содержащий неинициализированную переменную, но не печатает имя переменной.
Запуск Linux под VirtualBox не влияет на Valgrind.
Ответ 2
Я тоже компилировался с флагом -g
и по-прежнему не получал номера строк. После удаления каталога .dSYM
для моего приложения и выполнения valgrind с опцией --dsymutil=yes
, я наконец получил номера строк.
Ответ 3
Во многих дистрибутивах версия glibc по умолчанию не содержит символов отладки.
Попробуйте установить пакет libc6-dbg.
Ответ 4
вы должны скомпилировать его с помощью "-g".
gcc -g test.c -o test
а потом
valgrind --track-originins = yes --leak-check = full./test
Ответ 5
Обратите внимание, что запуск valgrind с решением --dsymutil = yes выполняется только для Mac OS X.
Согласно документам:
- dsymutil= нет | да [нет] Эта опция применима только при запуске Valgrind в Mac OS X.
Mac OS X использует схему привязки отложенной информации (debuginfo). Когда объектные файлы, содержащие debuginfo, связаны с .dylib или исполняемый файл, debuginfo не копируется в окончательный файл. Вместо, debuginfo должен быть связан вручную, запустив dsymutil, a системную утилиту, на исполняемый файл или .dylib. Результирующий комбинированный debuginfo помещается в каталог вместе с исполняемым файлом или .dylib, но с расширением .dSYM.
Ответ 6
попробуйте gcc not cc
cc не предоставляет номера строк, но gcc делает
Ответ 7
Я преследовал эту проблему, и ни один из других ответов не работал. Мой вывод отображал правильные символы, но номера строк не присутствовали.
В моем случае это было связано с рассматриваемой библиотекой с использованием .zdebug информации о количестве сжатых строк, а версия valgrind, которую я использовал, была старой и еще не имела необходимого патча [0].
Решением было обновление valgrind до последней версии.
[0] https://bugs.kde.org/show_bug.cgi?id=303877