*** 检测到 glibc *** sendip: free(): 下一个大小无效（正常）：0x09da25e8 ***
这是一个 C++ 问题（尽管是一个“C++ 被滥用”的问题）。替代重复： 面临错误：glibc 检测到免费无效的下一个大小（快）
我正在使用 Linux 工具来生成一些 n/w 流量，但是当我尝试发送大于某个长度的数据而该工具已提供此功能时，会出现此错误。
我的整个项目都陷入了这两者之间。由于我还没有创建该工具，所以不确定错误到底发生在哪里......并且这个错误（甚至gdb）没有给出任何关于问题出在哪里的提示。如何检测问题的点错误？
如果有帮助的话，我会提供一些问题的快照。请指导我应该如何进行？对我来说它看起来像一个网格。
udit@udit-Dabba ~ $ sendip -v -p ipv6 -f file.txt -6s ::1 -p esp -es 0x20 -eq 0x40 -ei
abcd -eI zxc -p tcp -ts 21 -td 21 ::2 | more
*** glibc detected *** sendip: free(): invalid next size (normal): 0x09da25e8 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6b961)[0x17b961]
/lib/i386-linux-gnu/libc.so.6(+0x6d28b)[0x17d28b]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0x18041d]
/lib/i386-linux-gnu/libc.so.6(fclose+0x14a)[0x16b9ca]
/lib/i386-linux-gnu/libc.so.6(+0xe053f)[0x1f053f]
/lib/i386-linux-gnu/libc.so.6(__res_ninit+0x25)[0x1f0815]
/lib/i386-linux-gnu/libc.so.6(__res_maybe_init+0x130)[0x1f1810]
/lib/i386-linux-gnu/libc.so.6(__nss_hostname_digits_dots+0x34)[0x1f37d4]
/lib/i386-linux-gnu/libc.so.6(gethostbyname2+0x96)[0x1f82f6]
/usr/local/lib/sendip/ipv6.so(set_addr+0x2d)[0x3eec69]
sendip(main+0x8eb)[0x804a635]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x126e37]
sendip[0x8048f81]
======= Memory map: ========
00110000-0026a000 r-xp 00000000 08:07 3408705 /lib/i386-linux-gnu/libc-2.13.so
0026a000-0026b000 ---p 0015a000 08:07 3408705 /lib/i386-linux-gnu/libc-2.13.so
0026b000-0026d000 r--p 0015a000 08:07 3408705 /lib/i386-linux-gnu/libc-2.13.so
0026d000-0026e000 rw-p 0015c000 08:07 3408705 /lib/i386-linux-gnu/libc-2.13.so
0026e000-00271000 rw-p 00000000 00:00 0
002d6000-002da000 r-xp 00000000 08:07 923078 /usr/local/lib/sendip/tcp.so
002da000-002db000 r--p 00003000 08:07 923078 /usr/local/lib/sendip/tcp.so
002db000-002dc000 rw-p 00004000 08:07 923078 /usr/local/lib/sendip/tcp.so
002dc000-002e0000 rw-p 00000000 00:00 0
003ee000-003f0000 r-xp 00000000 08:07 923076 /usr/local/lib/sendip/ipv6.so
003f0000-003f1000 r--p 00001000 08:07 923076 /usr/local/lib/sendip/ipv6.so
003f1000-003f2000 rw-p 00002000 08:07 923076 /usr/local/lib/sendip/ipv6.so
005fd000-00621000 r-xp 00000000 08:07 3408742 /lib/i386-linux-gnu/libm-2.13.so
00621000-00622000 r--p 00023000 08:07 3408742 /lib/i386-linux-gnu/libm-2.13.so
00622000-00623000 rw-p 00024000 08:07 3408742 /lib/i386-linux-gnu/libm-2.13.so
006f7000-006fa000 r-xp 00000000 08:07 919265 /usr/local/lib/sendip/esp.so
006fa000-006fb000 r--p 00002000 08:07 919265 /usr/local/lib/sendip/esp.so
006fb000-006fc000 rw-p 00003000 08:07 919265 /usr/local/lib/sendip/esp.so
006fc000-00700000 rw-p 00000000 00:00 0
0081a000-00836000 r-xp 00000000 08:07 3408692 /lib/i386-linux-gnu/ld-2.13.so
00836000-00837000 r--p 0001b000 08:07 3408692 /lib/i386-linux-gnu/ld-2.13.so
00837000-00838000 rw-p 0001c000 08:07 3408692 /lib/i386-linux-gnu/ld-2.13.so
0091d000-0091f000 r-xp 00000000 08:07 3408715 /lib/i386-linux-gnu/libdl-2.13.so
0091f000-00920000 r--p 00001000 08:07 3408715 /lib/i386-linux-gnu/libdl-2.13.so
00920000-00921000 rw-p 00002000 08:07 3408715 /lib/i386-linux-gnu/libdl-2.13.so
009e7000-00a01000 r-xp 00000000 08:07 3408733 /lib/i386-linux-gnu/libgcc_s.so.1
00a01000-00a02000 r--p 00019000 08:07 3408733 /lib/i386-linux-gnu/libgcc_s.so.1
00a02000-00a03000 rw-p 0001a000 08:07 3408733 /lib/i386-linux-gnu/libgcc_s.so.1
00fb3000-00fb4000 r-xp 00000000 00:00 0 [vdso]
08048000-0804e000 r-xp 00000000 08:07 923064 /usr/local/bin/sendip
0804e000-0804f000 r--p 00005000 08:07 923064 /usr/local/bin/sendip
0804f000-08050000 rw-p 00006000 08:07 923064 /usr/local/bin/sendip
08050000-08054000 rw-p 00000000 00:00 0
09da1000-09dc2000 rw-p 00000000 00:00 0 [heap]
b7600000-b7621000 rw-p 00000000 00:00 0
b7621000-b7700000 ---p 00000000 00:00 0
b77ce000-b77d0000 rw-p 00000000 00:00 0
b77e1000-b77e2000 rw-p 00000000 00:00 0
b77e2000-b77e3000 r--s 00000000 08:07 3148711 /home/udit/file.txt
b77e3000-b77e5000 rw-p 00000000 00:00 0
bfb5a000-bfb7b000 rw-p 00000000 00:00 0 [stack]
esp
Added 43 options
Initializing module ipv6
Initializing module esp
Initializing module tcp
我的 glibc 版本..
udit@udit-Dabba ~/Downloads/sendip-2.5-mec-2 $ ldd --version
ldd (Ubuntu EGLIBC 2.13-0ubuntu13) 2.13
...
它是一个开源工具 sendip，我正在尝试生成 ipsec 流量。如果需要任何代码部分，我将在此处添加它，但没有时间报告错误并等待它被修复，因为 acc。对于工具规格，我根据自己的目的选择它，但现在我完全陷入了两者之间。请为此指导我。
我知道，即使不查看代码，也几乎不可能知道错误是什么以及错误在哪里。我只是请求您的帮助和建议，在这种情况下我应该做什么，因为这甚至不完全是我的错误。
如果有人可以告诉我任何工具可以告诉我问题到底出在哪里？？？
我什至不确定这个问题是否适合在这里；如果没有请告诉我将其迁移到哪里？
按照建议，我尝试使用 valgrind 。我以前从未听说过它，所以不知道如何继续这里的输出。请指导我如何进一步进行？
udit@udit-Dabba ~ $ valgrind --leak-check=yes sendip -v -p ipv6
-f file.txt -6s ::1 -p esp -es 0x20 -eq 0x40 -ei abcd -eI zxc
-p tcp -ts 21 -td 21 ::2
==12444== Memcheck, a memory error detector
==12444== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==12444== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==12444== Command: sendip -v -p ipv6 -f file.txt -6s ::1 -p esp
-es 0x20 -eq 0x40 -ei abcd -eI zxc -p tcp -ts 21 -td 21 ::2
==12444==
esp
Added 43 options
Initializing module ipv6
Initializing module esp
Initializing module tcp
==12444== Invalid write of size 1
==12444== at 0x4027F40: memcpy (mc_replace_strmem.c:635)
==12444== by 0x4032269: do_opt (esp.c:113)
==12444== by 0x804A51D: main (sendip.c:575)
==12444== Address 0x41cec5c is 5 bytes after a block of size 23 alloc'd
==12444== at 0x402699A: realloc (vg_replace_malloc.c:525)
==12444== by 0x4032231: do_opt (esp.c:111)
==12444== by 0x804A51D: main (sendip.c:575)
==12444==
Finalizing module tcp
Finalizing module esp
Finalizing module ipv6
Final packet data:
60 00 00 00 `...
00 5B 32 20 .[2
/*rest packet content*/
65 66 0A 0A ef..
00 00 02 06 ....
1E 97 1E ...
Couldn't open RAW socket: Operation not permitted
Freeing module ipv6
Freeing module esp
Freeing module tcp
==12444==
==12444== HEAP SUMMARY:
==12444== in use at exit: 16 bytes in 1 blocks
==12444== total heap usage: 118 allocs, 117 frees, 8,236 bytes allocated
==12444==
==12444== 16 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12444== at 0x40268A4: malloc (vg_replace_malloc.c:236)
==12444== by 0x4031F47: ???
==12444== by 0x804A34F: main (sendip.c:517)
==12444==
==12444== LEAK SUMMARY:
==12444== definitely lost: 16 bytes in 1 blocks
==12444== indirectly lost: 0 bytes in 0 blocks
==12444== possibly lost: 0 bytes in 0 blocks
==12444== still reachable: 0 bytes in 0 blocks
==12444== suppressed: 0 bytes in 0 blocks
==12444==
==12444== For counts of detected and suppressed errors, rerun with: -v
==12444== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 30 from 11)
Possible Duplicate:
C++ Error: free(): invalid next size (fast):
That's a C++ question (albeit a 'C++ being abused' question). Alternative duplicate: Facing an error: glibc detected free invalid next size (fast)
I am using a Linux tool to generate some n/w traffic but getting this error when i try to send data greater than some length while the tool has provision for it.
My whole project has stuck in between. As I have not created the tool so not sure where exactly is the error occurring... and this error(even gdb) is not giving any hint regarding where is the problem.How to detect the point of error?
I am giving some snapshots of the problem if they help. Please guide me how should I proceed? It's looking like a mesh to me.
udit@udit-Dabba ~ $ sendip -v -p ipv6 -f file.txt -6s ::1 -p esp -es 0x20 -eq 0x40 -ei
abcd -eI zxc -p tcp -ts 21 -td 21 ::2 | more
*** glibc detected *** sendip: free(): invalid next size (normal): 0x09da25e8 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6b961)[0x17b961]
/lib/i386-linux-gnu/libc.so.6(+0x6d28b)[0x17d28b]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0x18041d]
/lib/i386-linux-gnu/libc.so.6(fclose+0x14a)[0x16b9ca]
/lib/i386-linux-gnu/libc.so.6(+0xe053f)[0x1f053f]
/lib/i386-linux-gnu/libc.so.6(__res_ninit+0x25)[0x1f0815]
/lib/i386-linux-gnu/libc.so.6(__res_maybe_init+0x130)[0x1f1810]
/lib/i386-linux-gnu/libc.so.6(__nss_hostname_digits_dots+0x34)[0x1f37d4]
/lib/i386-linux-gnu/libc.so.6(gethostbyname2+0x96)[0x1f82f6]
/usr/local/lib/sendip/ipv6.so(set_addr+0x2d)[0x3eec69]
sendip(main+0x8eb)[0x804a635]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x126e37]
sendip[0x8048f81]
======= Memory map: ========
00110000-0026a000 r-xp 00000000 08:07 3408705 /lib/i386-linux-gnu/libc-2.13.so
0026a000-0026b000 ---p 0015a000 08:07 3408705 /lib/i386-linux-gnu/libc-2.13.so
0026b000-0026d000 r--p 0015a000 08:07 3408705 /lib/i386-linux-gnu/libc-2.13.so
0026d000-0026e000 rw-p 0015c000 08:07 3408705 /lib/i386-linux-gnu/libc-2.13.so
0026e000-00271000 rw-p 00000000 00:00 0
002d6000-002da000 r-xp 00000000 08:07 923078 /usr/local/lib/sendip/tcp.so
002da000-002db000 r--p 00003000 08:07 923078 /usr/local/lib/sendip/tcp.so
002db000-002dc000 rw-p 00004000 08:07 923078 /usr/local/lib/sendip/tcp.so
002dc000-002e0000 rw-p 00000000 00:00 0
003ee000-003f0000 r-xp 00000000 08:07 923076 /usr/local/lib/sendip/ipv6.so
003f0000-003f1000 r--p 00001000 08:07 923076 /usr/local/lib/sendip/ipv6.so
003f1000-003f2000 rw-p 00002000 08:07 923076 /usr/local/lib/sendip/ipv6.so
005fd000-00621000 r-xp 00000000 08:07 3408742 /lib/i386-linux-gnu/libm-2.13.so
00621000-00622000 r--p 00023000 08:07 3408742 /lib/i386-linux-gnu/libm-2.13.so
00622000-00623000 rw-p 00024000 08:07 3408742 /lib/i386-linux-gnu/libm-2.13.so
006f7000-006fa000 r-xp 00000000 08:07 919265 /usr/local/lib/sendip/esp.so
006fa000-006fb000 r--p 00002000 08:07 919265 /usr/local/lib/sendip/esp.so
006fb000-006fc000 rw-p 00003000 08:07 919265 /usr/local/lib/sendip/esp.so
006fc000-00700000 rw-p 00000000 00:00 0
0081a000-00836000 r-xp 00000000 08:07 3408692 /lib/i386-linux-gnu/ld-2.13.so
00836000-00837000 r--p 0001b000 08:07 3408692 /lib/i386-linux-gnu/ld-2.13.so
00837000-00838000 rw-p 0001c000 08:07 3408692 /lib/i386-linux-gnu/ld-2.13.so
0091d000-0091f000 r-xp 00000000 08:07 3408715 /lib/i386-linux-gnu/libdl-2.13.so
0091f000-00920000 r--p 00001000 08:07 3408715 /lib/i386-linux-gnu/libdl-2.13.so
00920000-00921000 rw-p 00002000 08:07 3408715 /lib/i386-linux-gnu/libdl-2.13.so
009e7000-00a01000 r-xp 00000000 08:07 3408733 /lib/i386-linux-gnu/libgcc_s.so.1
00a01000-00a02000 r--p 00019000 08:07 3408733 /lib/i386-linux-gnu/libgcc_s.so.1
00a02000-00a03000 rw-p 0001a000 08:07 3408733 /lib/i386-linux-gnu/libgcc_s.so.1
00fb3000-00fb4000 r-xp 00000000 00:00 0 [vdso]
08048000-0804e000 r-xp 00000000 08:07 923064 /usr/local/bin/sendip
0804e000-0804f000 r--p 00005000 08:07 923064 /usr/local/bin/sendip
0804f000-08050000 rw-p 00006000 08:07 923064 /usr/local/bin/sendip
08050000-08054000 rw-p 00000000 00:00 0
09da1000-09dc2000 rw-p 00000000 00:00 0 [heap]
b7600000-b7621000 rw-p 00000000 00:00 0
b7621000-b7700000 ---p 00000000 00:00 0
b77ce000-b77d0000 rw-p 00000000 00:00 0
b77e1000-b77e2000 rw-p 00000000 00:00 0
b77e2000-b77e3000 r--s 00000000 08:07 3148711 /home/udit/file.txt
b77e3000-b77e5000 rw-p 00000000 00:00 0
bfb5a000-bfb7b000 rw-p 00000000 00:00 0 [stack]
esp
Added 43 options
Initializing module ipv6
Initializing module esp
Initializing module tcp
My glibc version ..
udit@udit-Dabba ~/Downloads/sendip-2.5-mec-2 $ ldd --version
ldd (Ubuntu EGLIBC 2.13-0ubuntu13) 2.13
...
It's an open source tool sendip and I am trying to generate ipsec traffic. If any code portion will be required I will add it here but don't have time to report the bug and wait for it to be fixed because acc. to the tool specifications i choose it for my purpose and now I am completely stuck in between. Please guide me for this.
I know it's almost impossible to tell what is the error and where it is without even looking at the code. I am just asking for your help and suggestion what should I do in this situation because its not even completely my mistake.
If anyone could tell me any tool which could tell me where exactly is the problem ????
I am not even sure whether the question is suitable for here; if not please tell me where to migrate it?
As suggested I tried with valgrind. I never even heard about it before so no idea how to proceed with here is the output. Please guide me how to go about it further?
udit@udit-Dabba ~ $ valgrind --leak-check=yes sendip -v -p ipv6
-f file.txt -6s ::1 -p esp -es 0x20 -eq 0x40 -ei abcd -eI zxc
-p tcp -ts 21 -td 21 ::2
==12444== Memcheck, a memory error detector
==12444== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==12444== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==12444== Command: sendip -v -p ipv6 -f file.txt -6s ::1 -p esp
-es 0x20 -eq 0x40 -ei abcd -eI zxc -p tcp -ts 21 -td 21 ::2
==12444==
esp
Added 43 options
Initializing module ipv6
Initializing module esp
Initializing module tcp
==12444== Invalid write of size 1
==12444== at 0x4027F40: memcpy (mc_replace_strmem.c:635)
==12444== by 0x4032269: do_opt (esp.c:113)
==12444== by 0x804A51D: main (sendip.c:575)
==12444== Address 0x41cec5c is 5 bytes after a block of size 23 alloc'd
==12444== at 0x402699A: realloc (vg_replace_malloc.c:525)
==12444== by 0x4032231: do_opt (esp.c:111)
==12444== by 0x804A51D: main (sendip.c:575)
==12444==
Finalizing module tcp
Finalizing module esp
Finalizing module ipv6
Final packet data:
60 00 00 00 `...
00 5B 32 20 .[2
/*rest packet content*/
65 66 0A 0A ef..
00 00 02 06 ....
1E 97 1E ...
Couldn't open RAW socket: Operation not permitted
Freeing module ipv6
Freeing module esp
Freeing module tcp
==12444==
==12444== HEAP SUMMARY:
==12444== in use at exit: 16 bytes in 1 blocks
==12444== total heap usage: 118 allocs, 117 frees, 8,236 bytes allocated
==12444==
==12444== 16 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12444== at 0x40268A4: malloc (vg_replace_malloc.c:236)
==12444== by 0x4031F47: ???
==12444== by 0x804A34F: main (sendip.c:517)
==12444==
==12444== LEAK SUMMARY:
==12444== definitely lost: 16 bytes in 1 blocks
==12444== indirectly lost: 0 bytes in 0 blocks
==12444== possibly lost: 0 bytes in 0 blocks
==12444== still reachable: 0 bytes in 0 blocks
==12444== suppressed: 0 bytes in 0 blocks
==12444==
==12444== For counts of detected and suppressed errors, rerun with: -v
==12444== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 30 from 11)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
可能你已经严重破坏了内存，在不应该写的地方写了东西（例如，由于缓冲区溢出）。
如果您想知道缓冲区溢出如何导致“无效释放”错误，请考虑以下示例。
假设您动态分配了一个 10 字节的数组 A，然后分配了一个结构体 B。C
运行时通常会将由 malloc/new 释放的已分配内存块的信息放在返回给用户的地址之前，因此很容易取回自由调用时的大小。
现在，假设您弄乱了数组下标并执行 A[11] = value。您的值将被放置在 C 运行时保留的字段中，用于存储上述信息，使它们变得毫无意义，因此 C 运行时将捕获尝试释放 B 的错误并中止执行。
由于您使用的是 Linux，因此可以使用 Valgrind 来追踪问题并消除它。
Probably you've messed badly with memory, writing things where you shouldn't (e.g., due to buffer overflows).
If you are wondering how a buffer overflow can cause an "invalid free" error, then consider the following example.
Suppose you've allocated dynamically an array A of 10 bytes, and then a structure B.
C runtimes usually places informations about allocated chunks of memory released by malloc/new just before the address returned to the user, so it is easy to get back the size at free invocation.
Now, suppose that you mess with array subscripts and do A[11] = value. Your value will be placed in the field reserved by the C runtime to store the aforementioned informations, turning them meaninglessness, so the C runtime will catch the error trying to free B and abort the execution.
Since you are on Linux, you can use Valgrind to track down the problem and eliminating it.
该错误消息意味着 glibc 检测到内存损坏，这是很糟糕的。
sendip程序可能有错误。例如，它可能在错误的时间或多次free()内存，或者可能存在杂散指针。我建议您向
sendip的作者报告此错误。向他们发送所有这些信息。我还建议您检查其开发人员提供的最新版本的
sendip，并尝试从其最新的源代码副本进行编译。最新版本可能修复了这个bug。如果您想尝试进一步排除故障，我建议在
valgrind下运行sendip命令行，然后将结果剪切并粘贴到此处并将其报告给开发人员发送。如果您安装了sendip的调试符号，或者在启用调试符号的情况下从源代码重新编译它，也会有所帮助。The error message means that glibc has detected memory corruption, which is bad. The
sendipprogram may have a bug. For instance, it may befree()ing memory at the wrong time, or multiple times, or there may be a stray pointer.I suggest that you report this bug to the authors of
sendip. Send them all of this information.I also suggest that you check what is the latest version of
sendip, available from its developers, and try compiling from their latest copy of the source code. It is possible that the latest version fixes this bug.If you want to try to troubleshoot further, I suggest running your
sendipcommand line undervalgrind, and then cut-and-paste the results here and report them to the developers ofsendip. It would also help if you installed debugging symbols forsendip, or recompiled it from source with debugging symbols enabled.valgrind 的输出直接指出了错误：
程序写入了它不应该写入的内存。
这是有问题的写入点的堆栈跟踪。
memcpy只是按照它的指示执行操作，因此错误位于 esp.c 第 113 行的do_opt中。根据优化情况，您可能会或可能不会在那里找到对memcpy的调用，但该区域中的某些东西正在尝试将内存块复制到错误的位置。该错误的根本原因可能是在计算副本的目标地址时。这描述了程序试图在何处写入不应该写入的内容。 “[malloced block] 之后的 5 个字节”正是那种会导致 glibc 的 malloc 发出原始错误消息的错误写入，它将（部分）其内部数据结构放在分配给应用程序使用的内存块之间。
顺便说一句，数字 12444 只是程序的进程 ID - 如果您在 valgrind 下运行调用
fork的程序，它会很有用，但在其他情况下可以忽略。The valgrind output is pointing you right at the bug:
The program wrote to memory that it shouldn't have.
This is a stack trace at the point of the offending write.
memcpyjust does what it's told, so the fault is indo_opt, at line 113 of esp.c. Depending on optimization, you may or may not find a call tomemcpythere, but something in that area is trying to copy a block of memory into the wrong place. The root cause of the bug is likely to be a bit above that, in the calculation of the destination address for the copy.This describes where the program tried to write that it shouldn't have. "5 bytes after a [malloced block]" is exactly the sort of bad write that would cause the original error message from glibc's malloc, which puts (some of) its internal data structures in between blocks of memory allocated for the application's use.
Incidentally, the number 12444 is just the process ID of the program - it's useful if you're running something that calls
forkunder valgrind, but otherwise can be ignored.