I have started using valgrind just one day ago as suggested by someone on SO itself .Its an amazing tool but today i got an issue with it.It gives the following error : definitely lost bytes but unable to tell the location of error.
Here is the output of 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)
Where exactly is the error ????
Actually i am linking the xorauth.so file in the command here and it fills some
authentication data in an optional field but it is unable to do so.
No optional authentication data apppearing at its position after running the command andvalgrind also says definitely lost bytes but it does not tell where is the problem ?
Also I tried with this variation of 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)
I don't understand this output i don't see any file named dl-error,etc... in the folder. Pleas tell me a right way to patch the problem.
EDIT:
As suggested I should use gcc with -g option to include debugging info ....but the problem is i am using make command and actually this implementation is not done by me.Its a standard packet generator tool and have some bug with it.I can't wait for the bug to be fixed so trying my own hand on it to fix it as my project has stucked in between due to this.So please tell me what should I do then .Is there a similiar switch for make or I have to change somewhere .As I am facing this situation first time so don't have any idea regarding how make and makefile works ?? If required I can add the contents of some files here.
sendip.c (line no. 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: }
output of make command
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
*Contents of 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 ..
This line:
==12885== by 0x804A51D: main (sendip.c:575)
indicates that the leaked memory was allocated at line 575 of sendip.c (by a function called on that line, which subsequently called down to malloc()). You can't see the name of that function because whichever file it was in was not compiled with debugging info.
So the offending line is:
if(!mod->do_opt(opts[longindex].name,gnuoptarg,mod->pack)) {
This indicates that the memory leak is within the function mod->do_opt(). do_opt is a function pointer within the structure mod, so you will need to find the point where this value is set to go deeper.
There are can be several reasons of bad stack traces given by Memcheck tool. All of them are listed in Valgrind FAQ - 4.2. The stack traces given by Memcheck (or another tool) aren't helpful. How can I improve them?. In this case you are using dlopen and dlclose while working with shared libs and therefore most likely debug info was discarded after dlclose and Valgrind failed to produce good stack trace. Workaround is to avoid calling dlclose.
Also, for leak reports involving shared objects, if the shared object is unloaded before the program terminates, Valgrind will discard the debug information and the error message will be full of ??? entries. The workaround here is to avoid calling dlclose on these shared objects.
You should build your program and libraries with debug information (the -g option for gcc). If you don't, valgrind can still find the leaks but cannot point out where in your source code the errors come from. The ??? in the backtraces suggest that debug information is not available -- many of those should show function names and line numbers when debug info is present.
来源：https://stackoverflow.com/questions/7655834/valgrind-giving-error-but-unable-to-find-location