C valgrind给出错误，但找不到位置_C_Memory Leaks_Makefile_Valgrind_Dlopen

C valgrind给出错误，但找不到位置

c memory-leaks makefile

C valgrind给出错误，但找不到位置,c,memory-leaks,makefile,valgrind,dlopen,C,Memory Leaks,Makefile,Valgrind,Dlopen,就在一天前，根据SO本身的建议，我开始使用valgrind。这是一个了不起的工具，但今天我遇到了一个问题。它给出了以下错误：肯定丢失了字节，但无法说出错误的位置以下是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

就在一天前，根据SO本身的建议，我开始使用

valgrind

。这是一个了不起的工具，但今天我遇到了一个问题。它给出了以下错误：

肯定丢失了字节

，但无法说出错误的位置

以下是

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)

  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)

错误到底在哪里

实际上我正在链接命令中的
xorauth.so
文件，它填充了一些
验证数据位于可选字段中，但无法执行此操作。
运行命令后，在其位置上没有显示可选的身份验证数据，并且

valgrind
还说
肯定丢失了字节
，但它不知道问题出在哪里？我还尝试了
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)

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的文件，等等。。。在文件夹中。请告诉我解决这个问题的正确方法
编辑： 正如建议的那样，我应该使用
gcc
和
-g
选项来包含调试信息……但问题是我使用make命令，实际上这个实现不是我自己完成的。它是一个标准的数据包生成器工具，并且有一些错误。我不能等待错误被修复，所以我尝试自己动手修复它作为我的项目由于这个原因，我在这段时间内遇到了问题。那么请告诉我应该怎么做。是否有类似的开关用于
make
，或者我必须在某个地方进行更改。因为我是第一次遇到这种情况，所以我不知道make和makefile是如何工作的？？如果需要，我可以在这里添加一些文件的内容
sendip.c（行号575）
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的内容：*

您应该使用调试信息构建程序和库（gcc的
-g
选项）。如果您不这样做，valgrind仍然可以找到漏洞，但无法指出源代码中错误的来源。回溯中的
？
表明调试信息不可用——当存在调试信息时，其中许多信息应显示函数名和行号。
此行：

==12885== by 0x804A51D: main (sendip.c:575)
指示泄漏的内存是在
sendip.c
的第575行分配的（通过在该行上调用的函数，该函数随后调用
malloc（）
）。您无法看到该函数的名称，因为它所在的任何文件都没有使用调试信息编译

因此，令人不快的是：

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

这表示内存泄漏在函数
mod->do_opt（）
中
do_opt
是结构
mod
中的函数指针，因此您需要找到将此值设置为更深的点。
Memcheck tool给出的堆栈跟踪不良可能有几个原因。所有这些都列在Valgrind常见问题解答-。在这种情况下，您在使用共享lib时使用了
dlopen
和
dlclose
，因此很可能在
dlclose
之后丢弃了调试信息，Valgrind无法生成良好的堆栈跟踪。解决方法是避免调用
dlclose
此外，对于涉及共享对象的泄漏报告，如果共享对象如果在程序终止前卸载，Valgrind将丢弃调试信息和错误消息将充满？？？条目。这里的解决方法是避免在这些共享数据上调用dlclose 对象

dl函数来自动态链接器，它将共享库加载到程序中。因为内存仍然可以访问，所以它不是泄漏，也没有什么可担心的。实际上我没有直接使用
gcc
命令，我正在使用
make
我还应该用
make
做些什么，以便它包含调试信息。您可以尝试将它添加到
CFLAGS
环境变量中，例如
CFLAGS=“$CFLAGS-g”make
根据makefile的外观，它不只是
make
@UditGupta，而是应该已经使用调试信息构建它（已经使用了
-g
选项）。我建议此时查看caf的答案。另一个选项是
--keep debuginfo=yes
，然后Valgrind将保留调试信息以显示堆栈跟踪，代价是增加内存