Valgrind не показывает номера строк, несмотря на флаг -g (в Ubuntu 11.10 / VirtualBox) - PullRequest
61 голосов
/ 17 февраля 2012

Я следую «Изучить трудный путь», в частности главу о Valgrind . Эта глава дает вам заведомо неправильную программу, чтобы показать, как работает Valgrind.

Когда я запускаю упражнение под Valgrind, я не получаю номера строк в моей трассировке стека, просто «(ниже основной)» для ошибок.

Я определенно компилирую с флагом -g.

Мой вывод Valgrind выглядит следующим образом:

djb@twin:~/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 в виртуальной машине VirtualBox.

Спасибо за любую помощь.

Обновление

Кажется, что если я вызываю функцию из main() и эта функция содержит ошибку (например, неинициализированная переменная), то я делаю получаю трассировку к месту, где функция была вызвана в main(). Однако ошибки в пределах main() остаются неуказанными. См. эту пасту для примера.

Ответы [ 7 ]

56 голосов
/ 05 марта 2012

Вывод, который вы указали в своем вопросе, содержит следующую строку:

==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.

16 голосов
/ 23 июля 2013

Я тоже компилировал с флагом -g и до сих пор не получил номера строк.После удаления каталога .dSYM для моего приложения и запуска valgrind с параметром --dsymutil=yes я наконец получил номера строк.

2 голосов
/ 26 февраля 2012

Во многих дистрибутивах версия glibc по умолчанию не содержит символов отладки.

Попробуйте установить пакет libc6-dbg.

1 голос
/ 24 ноября 2015

Обратите внимание, что запуск valgrind с решением --dsymutil = yes подходит только для Mac OS X.

Согласно документации:

- dsymutil = нет | да [нет] Этот параметр важен только при запуске Valgrind в Mac OS X.

Mac OS X использует схему связывания с отложенной информацией отладки (debuginfo).Когда объектные файлы, содержащие debuginfo, связаны с .dylib или исполняемым файлом, debuginfo не копируется в конечный файл.Вместо этого debuginfo необходимо связать вручную, запустив в исполняемом файле или .dylib системную утилиту dsymutil.Полученный комбинированный debuginfo помещается в каталог рядом с исполняемым файлом или .dylib, но с расширением .dSYM.

1 голос
/ 10 сентября 2014

вы должны скомпилировать его с "-g". gcc -g test.c -o test а потом valgrind --track-originins = yes --leak-check = full ./test

1 голос
/ 20 июня 2013

попробуйте gcc not cc

cc не предоставляет номера строк, но gcc делает

0 голосов
/ 01 декабря 2016

Я преследовал эту проблему, и ни один из других ответов не сработал. Мой вывод отображал правильные символы, но номера строк отсутствовали.

В моем случае это было связано с тем, что рассматриваемая библиотека использовала информацию о сжатой строке .zdebug, а используемая мной версия valgrind была старой и еще не имела необходимого патча [0].

Решением было обновить valgrind до последней версии.

[0] https://bugs.kde.org/show_bug.cgi?id=303877

...