Valgrind дает ошибку, но не может найти местоположение - PullRequest
Новая
       16

Valgrind дает ошибку, но не может найти местоположение

3 голосов
/ 05 октября 2011

Я начал использовать valgrind всего один день назад, как это было предложено кем-то на самой SO. Это удивительный инструмент, но сегодня у меня возникла проблема с ним. Он выдает следующую ошибку: definitely lost bytes, но не может определить местоположение ошибки.

Вот вывод valgrind: 

 udit@udit-Dabba ~ $  valgrind --leak-check=full  sendip -v -p ipv6 
 -f file.txt -6s ::1 -p ah -as 0x20 -aq 0x40 -ak "yugal" -am xorauth.so
 -p udp -us 21 -  ud 21 ::2 

 ==12885== Memcheck, a memory error detector
 ==12885== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
 ==12885== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
 ==12885== Command: sendip -v -p ipv6 -f file.txt -6s ::1 -p ah 
 -as 0x20 -aq 0x40 -ak "yugal" -am xorauth.so -p udp -us 21 -ud 21 ::2
 ==12885== 
 Added 19 options
 Initializing module ipv6
 Initializing module ah
 Initializing module udp
 Finalizing module udp
 Finalizing module ah
 Finalizing module ipv6
 Final packet data:
 60 00 00 00   `...
 00 38 33 20   .83 
 /*rest packet data*/
 73 62 68 64   sbhd
 66 67 68 79   fghy
 68 61 62 63   habc
Freeing module ipv6
Freeing module ah
Freeing module udp
==12885== 
==12885== HEAP SUMMARY:
==12885==     in use at exit: 875 bytes in 7 blocks
==12885==   total heap usage: 115 allocs, 108 frees, 9,587 bytes allocated
==12885== 
==12885== 52 (16 direct, 36 indirect) bytes in 1 blocks are definitely 
lost in loss record 5 of 7
==12885==    at 0x40268A4: malloc (vg_replace_malloc.c:236)
==12885==    by 0x4032ADA: ???
==12885==    by 0x40320EF: ???
==12885==    by 0x804A51D: main (sendip.c:575)
==12885== 
==12885== LEAK SUMMARY:
==12885==    definitely lost: 16 bytes in 1 blocks
==12885==    indirectly lost: 36 bytes in 1 blocks
==12885==      possibly lost: 0 bytes in 0 blocks
==12885==    still reachable: 823 bytes in 5 blocks
==12885==         suppressed: 0 bytes in 0 blocks
==12885== Reachable blocks (those to which a pointer was found) are not shown.
==12885== To see them, rerun with: --leak-check=full --show-reachable=yes
==12885== 
==12885== For counts of detected and suppressed errors, rerun with: -v
==12885== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 35 from 11)

Где именно ошибка ????

На самом деле я связываю здесь файл xorauth.so в команде, и он заполняет некоторые
данные аутентификации в необязательном поле, но это невозможно сделать.

Необязательные данные аутентификации появляются на своей позиции после выполнения команды и
valgrind также говорит definitely lost bytes но это не говорит, в чем проблема? Также я попробовал с этим вариантом valgrind: 

  udit@udit-Dabba ~ $  valgrind --leak-check=full --show-reachable=yes 
  sendip -v -p ipv6 -f file.txt -6s ::1 -p ah -as 0x20 -aq 0x40 
  -ak "yugal" -am xorauth.so -p udp -us 21 -ud 21 ::2 

  ==12893== Memcheck, a memory error detector
  ==12893== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
  ==12893== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
  ==12893== Command: sendip -v -p ipv6 -f file.txt -6s ::1 -p ah -as 0x20
 -aq 0x40 -ak yugal -am xorauth.so -p udp -us 21 -ud 21 ::2
 ==12893== 
 Added 19 options
 Initializing module ipv6
 Initializing module ah
 Initializing module udp
 Finalizing module udp
 Finalizing module ah
 Finalizing module ipv6
 Final packet data:
 60 00 00 00   `...
 00 38 33 20   .83 
 /*rest packet data*/
 66 67 68 79   fghy
 68 61 62 63   habc

 Freeing module ipv6
 Freeing module ah
 Freeing module udp
 ==12893== 
 ==12893== HEAP SUMMARY:
 ==12893==     in use at exit: 875 bytes in 7 blocks
 ==12893==   total heap usage: 115 allocs, 108 frees, 9,587 bytes allocated
 ==12893== 
 ==12893== 28 bytes in 1 blocks are still reachable in loss record 1 of 7
 ==12893==    at 0x40268A4: malloc (vg_replace_malloc.c:236)
 ==12893==    by 0x400CDE8: _dl_map_object_deps (dl-deps.c:510)
 ==12893==    by 0x40125BA: dl_open_worker (dl-open.c:263)
 ==12893==    by 0x400E4D5: _dl_catch_error (dl-error.c:178)
 ==12893==    by 0x4012145: _dl_open (dl-open.c:555)
 ==12893==    by 0x40408BA: dlopen_doit (dlopenold.c:55)
 ==12893==    by 0x400E4D5: _dl_catch_error (dl-error.c:178)
 ==12893==    by 0x40402CB: _dlerror_run (dlerror.c:164)
 ==12893==    by 0x4040936: dlopen@GLIBC_2.0 (dlopenold.c:77)
 ==12893==    by 0x4032BB3: ???
 ==12893==    by 0x40320EF: ???
 ==12893==    by 0x804A51D: main (sendip.c:575)
 ==12893== 
 ==12893== 33 bytes in 1 blocks are still reachable in loss record 2 of 7
 ==12893==    at 0x40268A4: malloc (vg_replace_malloc.c:236)
 ==12893==    by 0x4004E3E: local_strdup (dl-load.c:162)
 ==12893==    by 0x4007DD8: _dl_map_object (dl-load.c:2183)
 ==12893==    by 0x401255A: dl_open_worker (dl-open.c:226)
 ==12893==    by 0x400E4D5: _dl_catch_error (dl-error.c:178)
 ==12893==    by 0x4012145: _dl_open (dl-open.c:555)
 ==12893==    by 0x40408BA: dlopen_doit (dlopenold.c:55)
 ==12893==    by 0x400E4D5: _dl_catch_error (dl-error.c:178)
 ==12893==    by 0x40402CB: _dlerror_run (dlerror.c:164)
 ==12893==    by 0x4040936: dlopen@GLIBC_2.0 (dlopenold.c:77)
 ==12893==    by 0x4032BB3: ???
 ==12893==    by 0x40320EF: ???

 ==12893== 
 ==12893== 33 bytes in 1 blocks are still reachable in loss record 3 of 7
 ==12893==    at 0x40268A4: malloc (vg_replace_malloc.c:236)
 ==12893==    by 0x400AA70: _dl_new_object (dl-object.c:161)
 ==12893==    by 0x4005F8F: _dl_map_object_from_fd (dl-load.c:957)
 ==12893==    by 0x4007E92: _dl_map_object (dl-load.c:2250)
 ==12893==    by 0x401255A: dl_open_worker (dl-open.c:226)
 ==12893==    by 0x400E4D5: _dl_catch_error (dl-error.c:178)
 ==12893==    by 0x4012145: _dl_open (dl-open.c:555)
 ==12893==    by 0x40408BA: dlopen_doit (dlopenold.c:55)
 ==12893==    by 0x400E4D5: _dl_catch_error (dl-error.c:178)
 ==12893==    by 0x40402CB: _dlerror_run (dlerror.c:164)
 ==12893==    by 0x4040936: dlopen@GLIBC_2.0 (dlopenold.c:77)
 ==12893==    by 0x4032BB3: ???
 ==12893== 
 ==12893== 36 bytes in 1 blocks are indirectly lost in loss record 4 of 7
 ==12893==    at 0x40268A4: malloc (vg_replace_malloc.c:236)
 ==12893==    by 0x4032AF3: ???
 ==12893==    by 0x40320EF: ???
 ==12893==    by 0x804A51D: main (sendip.c:575)
 ==12893== 
 ==12893== 52 (16 direct, 36 indirect) bytes in 1 blocks are definitely
 lost in loss record 5 of 7
 ==12893==    at 0x40268A4: malloc (vg_replace_malloc.c:236)
 ==12893==    by 0x4032ADA: ???
 ==12893==    by 0x40320EF: ???
 ==12893==    by 0x804A51D: main (sendip.c:575)
 ==12893== 
 ==12893== 80 bytes in 1 blocks are still reachable in loss record 6 of 7
 ==12893==    at 0x4025355: calloc (vg_replace_malloc.c:467)   
 ==12893==    by 0x400FC84: _dl_check_map_versions (dl-version.c:300)
 ==12893==    by 0x4012810: dl_open_worker (dl-open.c:269)
 ==12893==    by 0x400E4D5: _dl_catch_error (dl-error.c:178)
 ==12893==    by 0x4012145: _dl_open (dl-open.c:555)
 ==12893==    by 0x40408BA: dlopen_doit (dlopenold.c:55)
 ==12893==    by 0x400E4D5: _dl_catch_error (dl-error.c:178)
 ==12893==    by 0x40402CB: _dlerror_run (dlerror.c:164)

 ==12893==    by 0x4040936: dlopen@GLIBC_2.0 (dlopenold.c:77)
 ==12893==    by 0x4032BB3: ???
 ==12893==    by 0x40320EF: ???
 ==12893==    by 0x804A51D: main (sendip.c:575)
 ==12893== 
 ==12893== 649 bytes in 1 blocks are still reachable in loss record 7 of 7
 ==12893==    at 0x4025355: calloc (vg_replace_malloc.c:467)
 ==12893==    by 0x400A842: _dl_new_object (dl-object.c:77)
 ==12893==    by 0x4005F8F: _dl_map_object_from_fd (dl-load.c:957)
 ==12893==    by 0x4007E92: _dl_map_object (dl-load.c:2250)
 ==12893==    by 0x401255A: dl_open_worker (dl-open.c:226)
 ==12893==    by 0x400E4D5: _dl_catch_error (dl-error.c:178)
 ==12893==    by 0x4012145: _dl_open (dl-open.c:555)
 ==12893==    by 0x40408BA: dlopen_doit (dlopenold.c:55)
 ==12893==    by 0x400E4D5: _dl_catch_error (dl-error.c:178)
 ==12893==    by 0x40402CB: _dlerror_run (dlerror.c:164)
 ==12893==    by 0x4040936: dlopen@GLIBC_2.0 (dlopenold.c:77)
 ==12893==    by 0x4032BB3: ???
 ==12893== 
 ==12893== LEAK SUMMARY:
 ==12893==    definitely lost: 16 bytes in 1 blocks
 ==12893==    indirectly lost: 36 bytes in 1 blocks
 ==12893==      possibly lost: 0 bytes in 0 blocks
 ==12893==    still reachable: 823 bytes in 5 blocks
 ==12893==         suppressed: 0 bytes in 0 blocks
 ==12893== 
 ==12893== For counts of detected and suppressed errors, rerun with: -v
 ==12893== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 35 from 11)

Я не понимаю этот вывод, я не вижу в папке ни одного файла с именем dl-error и т. Д. Пожалуйста, скажите мне правильный способ исправить проблему.

EDIT: Как и предполагалось, я должен использовать gcc с опцией -g, чтобы включить отладочную информацию .... но проблема в том, что я использую команду make, и на самом деле эта реализация не сделана мной. Это стандартное средство генерации пакетов и есть некоторая ошибка с этим. Я не могу дождаться исправления ошибки, поэтому стараюсь изо всех сил, чтобы исправить это, так как мой проект застрял из-за этого. Поэтому, пожалуйста, скажите мне, что мне тогда делать. для make или я должен где-то измениться. Поскольку я сталкиваюсь с этой ситуацией впервые, поэтому не имею никакого представления о том, как работают make и makefile ?? При необходимости я могу добавить содержимое некоторых файлов здесь.

sendip.c (строка № 575) 

  575:       if(!mod->do_opt(opts[longindex].name,gnuoptarg,mod->pack)) {
  576:       printf("go to hell");// added by me but not printed.
  577:       usage=TRUE; 
  578:       }

вывод команды make 

  udit@udit-Dabba ~/Downloads/sendip-2.5-mec-2 $ make
  for subdir in mec ; do \
    cd $subdir ;\
    make  ;\
    cd ..  ;\
    done
  make[1]: Entering directory `/home/udit/Downloads/sendip-2.5-mec-2/mec'
  make[1]: Nothing to be done for `all'.
  make[1]: Leaving directory `/home/udit/Downloads/sendip-2.5-mec-2/mec'
  gcc -fPIC -fsigned-char -pipe -Wall -Wpointer-arith -Wwrite-strings -Wstrict-   
  prototypes -Wnested-externs -Winline -Werror -g -Wcast-align - 
  DSENDIP_LIBS=\"/usr/local/lib/sendip\"   -c -o sendip.o sendip.c
  sh -c "if [ `uname` = Linux ] ; then \
  gcc -o sendip -g  -rdynamic -ldl -lm -fPIC -fsigned-char -pipe -Wall 
  -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wnested-externs
  -Winline -Werror -g -Wcast-align -DSENDIP_LIBS=\"/usr/local/lib/sendip\" 
  sendip.o gnugetopt.o gnugetopt1.o compact.o ; \
  elif [ `uname` = SunOS ] ; then \
  gcc -o sendip -g -lsocket -lnsl -lm -ldl -fPIC -fsigned-char -pipe -Wall
  -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wnested-externs
  -Winline -Werror -g -Wcast-align -DSENDIP_LIBS=\"/usr/local/lib/sendip\"
  sendip.o gnugetopt.o gnugetopt1.o compact.o ;\
  else \
  gcc -o sendip -g -rdynamic -lm -fPIC -fsigned-char -pipe -Wall 
  -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wnested-externs
  -Winline -Werror -g -Wcast-align -DSENDIP_LIBS=\"/usr/local/lib/sendip\"
  sendip.o gnugetopt.o gnugetopt1.o compact.o ; \
  fi"
  ./help2man -n "Send arbitrary IP packets" -N >sendip.1

* Содержимое Makefile: *

   #configureable stuff
   PREFIX ?= /usr/local
   BINDIR ?= $(PREFIX)/bin
   MANDIR ?= $(PREFIX)/share/man/man1
   LIBDIR ?= $(PREFIX)/lib/sendip
   #For most systems, this works
   INSTALL ?= install
   #For Solaris, you may need
   #INSTALL=/usr/ucb/install

   CFLAGS= -fPIC -fsigned-char -pipe -Wall -Wpointer-arith
   -Wwrite-strings \
   -Wstrict-prototypes -Wnested-externs -Winline -Werror -g -Wcast-align \
                    -DSENDIP_LIBS=\"$(LIBDIR)\"
   #-Wcast-align causes problems on solaris, but not serious ones
   LDFLAGS=        -g -rdynamic -lm
   #LDFLAGS_SOLARIS= -g -lsocket -lnsl -lm
   LDFLAGS_SOLARIS= -g -lsocket -lnsl -lm -ldl
   LDFLAGS_LINUX= -g  -rdynamic -ldl -lm
   LIBCFLAGS= -shared
   CC=     gcc

   PROGS= sendip
   BASEPROTOS= ipv4.so ipv6.so
   IPPROTOS= icmp.so tcp.so udp.so
   UDPPROTOS= rip.so ripng.so ntp.so
   TCPPROTOS= bgp.so
   PROTOS= $(BASEPROTOS) $(IPPROTOS) $(UDPPROTOS) $(TCPPROTOS)
   LIBS= libsendipaux.a
   LIBOBJS= csum.o compact.o protoname.o headers.o parseargs.o cryptomod.o crc32.o
   SUBDIRS= mec

   all:    $(LIBS) subdirs sendip $(PROTOS) sendip.1 sendip.spec

   #there has to be a nice way to do this
   sendip: sendip.o        gnugetopt.o gnugetopt1.o compact.o
    sh -c "if [ `uname` = Linux ] ; then \
   $(CC) -o $@ $(LDFLAGS_LINUX) $(CFLAGS) $+ ; \
   elif [ `uname` = SunOS ] ; then \
   $(CC) -o $@ $(LDFLAGS_SOLARIS) $(CFLAGS) $+ ;\
   else \
   $(CC) -o $@ $(LDFLAGS) $(CFLAGS) $+ ; \    
   fi"

   libsendipaux.a: $(LIBOBJS)
    ar vr $@ $?

   subdirs:
    for subdir in $(SUBDIRS) ; do \
            cd $$subdir ;\
            make  ;\
            cd ..  ;\
            done

   protoname.o:    mec/protoname.c
    $(CC) -o $@ -c -I. $(CFLAGS) $+

   headers.o:      mec/headers.c
    $(CC) -o $@ -c -I. $(CFLAGS) $+

   parseargs.o:    mec/parseargs.c
    $(CC) -o $@ -c -I. $(CFLAGS) $+

   cryptomod.o:    mec/cryptomod.c
    $(CC) -o $@ -c -I. $(CFLAGS) $+

   crc32.o: mec/crc32table.h mec/crc32.c
    $(CC) -o $@ -c -I. $(CFLAGS) mec/crc32.c

   mec/crc32table.h: mec/gen_crc32table
    mec/gen_crc32table > mec/crc32table.h

   sendip.1:       ./help2man $(PROGS) $(PROTOS) subdirs VERSION
                    ./help2man -n "Send arbitrary IP packets" -N >sendip.1

   sendip.spec:    sendip.spec.in VERSION
                    echo -n '%define ver ' >sendip.spec
                    cat VERSION >>sendip.spec
                    cat sendip.spec.in >>sendip.spec

    %.so: %.c $(LIBS)
                    $(CC) -o $@ $(CFLAGS) $(LIBCFLAGS) $+ $(LIBS)

   .PHONY: clean install

   clean:
                    rm -f *.o *~ *.so $(PROTOS) $(PROGS) $(LIBS) core gmon.out
                    for subdir in $(SUBDIRS) ; do \
                            cd $$subdir ;\
                            make clean ;\
                            cd ..  ;\
                            done

   veryclean:
                    make clean
                    rm -f sendip.spec sendip.1

   install:                all
                    [ -d $(LIBDIR) ] || mkdir -p $(LIBDIR)
                    [ -d $(BINDIR) ] || mkdir -p $(BINDIR)
                    [ -d $(MANDIR) ] || mkdir -p $(MANDIR)
                    $(INSTALL) -m 755 $(PROGS) $(BINDIR)
                    $(INSTALL) -m 644 sendip.1 $(MANDIR)
                    $(INSTALL) -m 755 $(PROTOS) $(LIBDIR)
                    for subdir in $(SUBDIRS) ; do \
                            cd $$subdir ;\
                            make install ;\
                            cd ..  ;\
                            done


     The problem is coming only with the module xorauth.so ,
     its not performing its work.So tell me how to include some 
     more debugging info ..

Ответы [ 3 ]

5 голосов
/ 05 октября 2011

Эта строка: 

==12885==    by 0x804A51D: main (sendip.c:575)

указывает, что утечка памяти была выделена в строке 575 из sendip.c (с помощью функции, вызываемой в этой строке, которая впоследствии вызывалась до malloc()).Вы не можете увидеть имя этой функции, потому что какой-либо файл, в котором она находилась, не был скомпилирован с отладочной информацией.

Таким образом, ошибочная строка: 

if(!mod->do_opt(opts[longindex].name,gnuoptarg,mod->pack)) {

Это означает, чтоутечка памяти находится в пределах функции mod->do_opt().do_opt - это указатель на функцию в структуре mod, поэтому вам нужно будет найти точку, где это значение будет установлено глубже.

3 голосов
/ 05 октября 2011

Может быть несколько причин плохой трассировки стека, предоставленной инструментом Memcheck.Все они перечислены в FAQ Valgrind - 4.2.Трассировки стека, данные Memcheck (или другим инструментом), не помогают.Как я могу улучшить их? .В этом случае вы используете dlopen и dlclose при работе с совместно используемыми библиотеками и, следовательно, наиболее вероятно, что отладочная информация была отброшена после dlclose, и Valgrind не смог произвести хорошую трассировку стека.Обходной путь - избегать вызова dlclose.

Кроме того, для отчетов об утечках, связанных с общими объектами, если общий объект выгружается до завершения программы, Valgrind отбрасывает отладочную информацию, и сообщение об ошибке будетполон ???записей.Обходной путь здесь состоит в том, чтобы избежать вызова dlclose для этих общих объектов.

2 голосов
/ 05 октября 2011

Вы должны собрать свою программу и библиотеки с отладочной информацией (опция -g для gcc). Если вы этого не сделаете, valgrind все еще может обнаружить утечки, но не сможет указать, откуда в вашем исходном коде произошли ошибки. ??? в обратных следах указывает на то, что отладочная информация недоступна - многие из них должны отображать имена функций и номера строк при наличии отладочной информации.

...