给Valgrind的错误，但无法找到位置 [英] valgrind giving error but unable to find location
本文介绍了给Valgrind的错误，但无法找到位置的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
作为SO本身。其惊人的工具，建议由某人我一直在使用的valgrind 开始仅仅一天前，但今天我有一个问题与it.It提供了以下错误：肯定失去了字节，但无法分辨错误的位置
下面是输出的valgrind ：
udit @ udit-Dabba〜$的valgrind --leak检查=全sendip -v -p的IPv6
-f file.txt的-6S :: 1 -p啊-as 0x20的-aq 0X40 -akyugal-am xorauth.so
-p UDP -us 21 - 21 UD：2 == == 12885 MEMCHECK，内存错误检测
== == 12885版权所有（C）2002-2010，和GNU GPL的，Julian Seward写等。
== == 12885 Valgrind的使用，3.6.1和LibVEX;与-h版权信息重新运行
== == 12885命令：sendip -v -p -f命令ipv6 file.txt的-6S :: 1 -p啊
-as 0x20的-aq 0X40 -akyugal-am xorauth.so -p UDP -us 21 -ud 21：2
== == 12885
新增19选项
初始化模块的IPv6
初始化模块啊
初始化模块UDP
最终处理UDP模块
最终处理模块啊
最终处理模块的IPv6
最后的分组数据：
60 00 00 00`...
00 38 33 20 0.83
/ *剩下的分组数据* /
73 62 68 64 sbhd
66 67 68 79 fghy
68 61 62 63 habc
释放模块的IPv6
释放模块啊
释放UDP模块
== == 12885
== == 12885 HEAP摘要：
== == 12885在退出，使用：875在7块字节
== == 12885总堆的使用情况：115 allocs，108的FreeS，分配9587字节
== == 12885
== == 12885 52（16直接，间接36）字节1块肯定
失去了在负的战绩5 7
== == 12885在0x40268A4：的malloc（vg_replace_malloc.c：236）
== == 12885通过0x4032ADA：???
== == 12885通过0x40320EF：???
== == 12885通过0x804A51D：主（sendip.c：575）
== == 12885
== == 12885泄漏摘要：
== == 12885失去了肯定：16字节1块
== == 12885间接失去了：36字节1块
== == 12885失去了可能：0字节0块
== == 12885尚能访问：5块823个字节
== == 12885燮pressed：0字节0块
== 12885 ==可达块（那些其中指针被发现）未示出。
== == 12885发现它们，重新运行：--leak检查=全--show-可达= YES
== == 12885
== == 12885侦测到并SUP pressed错误计数，重新运行：-v
== == 12885错误摘要：从1上下文1错误（SUP pressed：35 11）
到底在哪错误????
其实我链接在这里指挥了 xorauth.so 文件，它填补了一些结果
在可选字段的验证的数据，但它无法做到这一点。
无可选的认证数据在其位置apppearing运行命令和结果后，
的valgrind 还说肯定失去了字节，但它并没有告诉问题出在哪里？
我也试图与这个变化的valgrind ：
udit @ udit-Dabba〜$的valgrind --leak检查=全--show-可达= YES
sendip -v -p -f命令ipv6 file.txt的-6S :: 1 -p啊-as 0x20的-aq 0X40
-akyugal-am xorauth.so -p UDP -us 21 -ud 21：2 == == 12893 MEMCHECK，内存错误检测
== == 12893版权所有（C）2002-2010，和GNU GPL的，Julian Seward写等。
== == 12893 Valgrind的使用，3.6.1和LibVEX;与-h版权信息重新运行
== == 12893命令：sendip -v -p -f IPv6的file.txt的-6S :: 1 -p啊-as为0x20
-aq 0X40 -ak yugal -am xorauth.so -p UDP -us 21 -ud 21：2
== == 12893
新增19选项
初始化模块的IPv6
初始化模块啊
初始化模块UDP
最终处理UDP模块
最终处理模块啊
最终处理模块的IPv6
最后的分组数据：
60 00 00 00`...
00 38 33 20 0.83
/ *剩下的分组数据* /
66 67 68 79 fghy
68 61 62 63 habc 释放模块的IPv6
释放模块啊
释放UDP模块
== == 12893
== == 12893 HEAP摘要：
== == 12893在退出，使用：875在7块字节
== == 12893总堆的使用情况：115 allocs，108的FreeS，分配9587字节
== == 12893
== == 12893在1块28个字节仍处于负的战绩1可达7
== == 12893在0x40268A4：的malloc（vg_replace_malloc.c：236）
== == 12893通过0x400CDE8：_dl_map_object_deps（DL-deps.c：510）
== == 12893通过0x40125BA：dl_open_worker（DL-open.c：263）
== == 12893通过0x400E4D5：_dl_catch_error（DL-error.c：178）
== == 12893通过0x4012145：_dl_open（DL-open.c：555）
== == 12893通过0x40408BA：dlopen_doit（dlopenold.c：55）
== == 12893通过0x400E4D5：_dl_catch_error（DL-error.c：178）
== == 12893通过0x40402CB：_dlerror_run（dlerror.c：164）
== == 12893通过0x4040936：dlopen@GLIBC_2.0（dlopenold.c：77）
== == 12893通过0x4032BB3：???
== == 12893通过0x40320EF：???
== == 12893通过0x804A51D：主（sendip.c：575）
== == 12893
== == 12893在1块33个字节仍处于负的战绩2 7可达
== == 12893在0x40268A4：的malloc（vg_replace_malloc.c：236）
== == 12893通过0x4004E3E：local_strdup（DL-load.c：162）
== == 12893通过0x4007DD8：_dl_map_object（DL-load.c：2183）
== == 12893通过0x401255A：dl_open_worker（DL-open.c：226）
== == 12893通过0x400E4D5：_dl_catch_error（DL-error.c：178）
== == 12893通过0x4012145：_dl_open（DL-open.c：555）
== == 12893通过0x40408BA：dlopen_doit（dlopenold.c：55）
== == 12893通过0x400E4D5：_dl_catch_error（DL-error.c：178）
== == 12893通过0x40402CB：_dlerror_run（dlerror.c：164）
== == 12893通过0x4040936：dlopen@GLIBC_2.0（dlopenold.c：77）
== == 12893通过0x4032BB3：???
== == 12893通过0x40320EF：??? == == 12893
== == 12893在1块33个字节仍处于负的战绩3可达7
== == 12893在0x40268A4：的malloc（vg_replace_malloc.c：236）
== == 12893通过0x400AA70：_dl_new_object（DL-object.c：161）
== == 12893通过0x4005F8F：_dl_map_object_from_fd（DL-load.c：957）
== == 12893通过0x4007E92：_dl_map_object（DL-load.c：2250）
== == 12893通过0x401255A：dl_open_worker（DL-open.c：226）
== == 12893通过0x400E4D5：_dl_catch_error（DL-error.c：178）
== == 12893通过0x4012145：_dl_open（DL-open.c：555）
== == 12893通过0x40408BA：dlopen_doit（dlopenold.c：55）
== == 12893通过0x400E4D5：_dl_catch_error（DL-error.c：178）
== == 12893通过0x40402CB：_dlerror_run（dlerror.c：164）
== == 12893通过0x4040936：dlopen@GLIBC_2.0（dlopenold.c：77）
== == 12893通过0x4032BB3：???
== == 12893
== == 12893在1块36个字节是间接失去了在负的战绩4 7
== == 12893在0x40268A4：的malloc（vg_replace_malloc.c：236）
== == 12893通过0x4032AF3：???
== == 12893通过0x40320EF：???
== == 12893通过0x804A51D：主（sendip.c：575）
== == 12893
== == 12893 52（16直接，间接36）字节1块肯定
失去了在负的战绩5 7
== == 12893在0x40268A4：的malloc（vg_replace_malloc.c：236）
== == 12893通过0x4032ADA：???
== == 12893通过0x40320EF：???
== == 12893通过0x804A51D：主（sendip.c：575）
== == 12893
== == 12893在1块80个字节仍处于负的战绩6 7可到达
== == 12893在0x4025355：释放calloc（vg_replace_malloc.c：467）
== == 12893通过0x400FC84：_dl_check_map_versions（DL-version.c：300）
== == 12893通过0x4012810：dl_open_worker（DL-open.c：269）
== == 12893通过0x400E4D5：_dl_catch_error（DL-error.c：178）
== == 12893通过0x4012145：_dl_open（DL-open.c：555）
== == 12893通过0x40408BA：dlopen_doit（dlopenold.c：55）
== == 12893通过0x400E4D5：_dl_catch_error（DL-error.c：178）
== == 12893通过0x40402CB：_dlerror_run（dlerror.c：164） == == 12893通过0x4040936：dlopen@GLIBC_2.0（dlopenold.c：77）
== == 12893通过0x4032BB3：???
== == 12893通过0x40320EF：???
== == 12893通过0x804A51D：主（sendip.c：575）
== == 12893
== == 12893 649 1块字节仍处于负的战绩7 7可达
== == 12893在0x4025355：释放calloc（vg_replace_malloc.c：467）
== == 12893通过0x400A842：_dl_new_object（DL-object.c：77）
== == 12893通过0x4005F8F：_dl_map_object_from_fd（DL-load.c：957）
== == 12893通过0x4007E92：_dl_map_object（DL-load.c：2250）
== == 12893通过0x401255A：dl_open_worker（DL-open.c：226）
== == 12893通过0x400E4D5：_dl_catch_error（DL-error.c：178）
== == 12893通过0x4012145：_dl_open（DL-open.c：555）
== == 12893通过0x40408BA：dlopen_doit（dlopenold.c：55）
== == 12893通过0x400E4D5：_dl_catch_error（DL-error.c：178）
== == 12893通过0x40402CB：_dlerror_run（dlerror.c：164）
== == 12893通过0x4040936：dlopen@GLIBC_2.0（dlopenold.c：77）
== == 12893通过0x4032BB3：???
== == 12893
== == 12893泄漏摘要：
== == 12893失去了肯定：16字节1块
== == 12893间接失去了：36字节1块
== == 12893失去了可能：0字节0块
== == 12893尚能访问：5块823个字节
== == 12893燮pressed：0字节0块
== == 12893
== == 12893侦测到并SUP pressed错误计数，重新运行：-v
== == 12893错误摘要：从1上下文1错误（SUP pressed：35 11）
我不明白，这个输出我没有看到任何DL-错误文件命名，等...文件夹中。
普莱斯告诉我正确的方式打补丁的问题。
编辑：
作为建议我应该使用 GCC 与 -g 选项，包括调试信息....但问题是我是使用make命令，实际上这种实现不是由me.Its做一个标准的数据包生成工具，并与它。我一些bug不能等待固定的bug，因此想在我自己的手来修复它为我的项目由于已经与stucked中this.So请告诉我，我应该做的又是什么。是那里一个类似的开关让或我要改变的地方，我面临着这样的。至于情况第一次如此没有关于如何做和Makefile工作任何想法？如果需要，我可以在这里添加一些文件的内容。
sendip.c（号线。575）
575：如果（！MOD-＆GT; do_opt（选[longindex] .name和gnuoptarg的，模块＆GT;包））{
576：输出（下地狱）; //由我添加，但不打印。
577：用法= TRUE;
578：}
make命令的输出
udit @ udit-Dabba〜/下载/ sendip-2.5-MEC-2 $使
在MEC子目录;做\\
CD $子目录; \\
做; \\
CD ..; \\
DONE
使[1]：进入目录`/home/udit/Downloads/sendip-2.5-mec-2/mec
使[1]：为所有的''做什么也没有。
使[1]：离开目录`/home/udit/Downloads/sendip-2.5-mec-2/mec
GCC -fPIC -fsigned-CHAR -pipe -Wall -Wpointer-ARITH -Wwrite串-Wstrict-
原型-Wnested-实习医生-Winline -Werror -g -Wcast对齐 -
DSENDIP_LIBS = \\在/ usr / local / lib目录/ sendip \\-c -o sendip.o sendip.c
SH -c如果[`uname` = Linux的;然后\\
GCC -o sendip -g -rdynamic -ldl -lm -fPIC -fsigned-CHAR -pipe -Wall
-Wpointer-ARITH -Wwrite弦-Wstrict的原型-Wnested，实习医生
-Winline -Werror -g -Wcast对齐-DSENDIP_LIBS = \\在/ usr / local / lib目录/ sendip \\
sendip.o gnugetopt.o gnugetopt1.o compact.o; \\
ELIF [`uname` =的SunOS];然后 \\
GCC -o sendip -g -lsocket -lnsl -lm -ldl -fPIC -fsigned-CHAR -pipe -Wall
-Wpointer-ARITH -Wwrite弦-Wstrict的原型-Wnested，实习医生
-Winline -Werror -g -Wcast对齐-DSENDIP_LIBS = \\在/ usr / local / lib目录/ sendip \\
sendip.o gnugetopt.o gnugetopt1.o compact.o; \\
其他\\
GCC -o sendip -g -rdynamic -lm -fPIC -fsigned-CHAR -pipe -Wall
-Wpointer-ARITH -Wwrite弦-Wstrict的原型-Wnested，实习医生
-Winline -Werror -g -Wcast对齐-DSENDIP_LIBS = \\在/ usr / local / lib目录/ sendip \\
sendip.o gnugetopt.o gnugetopt1.o compact.o; \\
科幻
./help2man -n发送任意IP数据包-N＆GT; sendip.1
*的的Makefile的内容：* 的
#configureable东西
preFIX？=的/ usr /本地
BINDIR？= $（preFIX）/箱
MANDIR？= $（preFIX）/共享/人/ MAN1
LIBDIR？= $（preFIX）/ lib中/ sendip
#For大多数系统中，这个工程
安装？=安装
#For Solaris中，您可能需要
＃安装=的/ usr / UCB /安装 CFLAGS = -fPIC -fsigned-CHAR -pipe -Wall -Wpointer，ARITH
-Wwrite串\\
-Wstrict的原型-Wnested-实习医生-Winline -Werror -g -Wcast对齐\\
-DSENDIP_LIBS = \\$（LIBDIR）\\
＃-Wcast对齐导致在Solaris上的问题，但并不严重的人
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 所有：$（LIBS）子目录sendip $（PROTOS）sendip.1 sendip.spec #there必须有一个很好的办法做到这一点
sendip：sendip.o gnugetopt.o gnugetopt1.o compact.o
SH -c如果[`uname` = Linux的;然后\\
$（CC）-o $ @ $（LDFLAGS_LINUX）$（CFLAGS）$ +; \\
ELIF [`uname` =的SunOS];然后 \\
$（CC）-o $ @ $（LDFLAGS_SOLARIS）$（CFLAGS）$ +; \\
其他\\
$（CC）-o $ @ $（LDFLAGS）$（CFLAGS）$ +; \\
科幻 libsendipaux.a：$（LIBOBJS）
AR虚拟现实$ @ $？ 子目录：
在$（SUBDIRS）子目录;做\\
CD $$子目录; \\
做; \\
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＆GT; MEC / crc32table.h sendip.1：./help2man $（progs的）$（PROTOS）子目录VERSION
./help2man -n发送任意IP数据包-N＆GT; sendip.1 sendip.spec：sendip.spec.in VERSION
回声-n'％定义版本'＆GT; sendip.spec
猫版＆GT;＆GT; sendip.spec
猫sendip.spec.in＆GT;＆GT; sendip.spec ％。所以：％.C $（LIBS）
$（CC）-o $ @ $（CFLAGS）$（LIBCFLAGS）$ + $（LIBS） .PHONY：全新安装 清洁：
RM -f *的.o *〜*。所以$（PROTOS）$（progs的）$（LIBS）的核心是gmon.out
在$（SUBDIRS）子目录;做\\
CD $$子目录; \\
使清洁; \\
CD ..; \\
DONE 很干净：
使清洁
RM -f sendip.spec sendip.1 安装：所有
[-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）
在$（SUBDIRS）子目录;做\\
CD $$子目录; \\
使安装; \\
CD ..; \\
DONE
问题来仅与模块xorauth.so，
它不是履行work.So告诉我如何加入一些
更多的调试信息..
解决方案
这行：
== == 12885通过0x804A51D：主（sendip.c：575）
表示泄漏的内存在 sendip.c 575线（一个被称为该线路上的功能，随后传来叫分配的malloc（））。你看不到这种职能，因为任何文件，它是在不与调试信息编译的名称。
所以，有问题的行是：
如果（MOD-＆GT;！do_opt（选[longindex] .name和gnuoptarg的，模块＆GT;包））{
这表明该内存泄漏是函数内的 MOD-＆GT; do_opt（）。 do_opt 是结构中的函数指针 MOD ，所以你需要找到这个值设置为点深究下去。
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 and
valgrind 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.
这篇关于给Valgrind的错误，但无法找到位置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
查看全文
