这是一个C ++问题（虽然是'C ++被滥用'的问题）。替代副本：Facing an error: glibc detected free invalid next size (fast)
我正在使用Linux工具生成一些n / w流量，但是当我尝试发送大于某个长度的数据时会出现此错误，而该工具已为其提供了相应的功能。
我的整个项目都介于两者之间。因为我还没有创建工具所以不确定错误发生在哪里......而且这个错误（甚至gdb）没有给出关于问题所在位置的任何提示。如何检测错误点？ / p>
如果有问题，我会给出一些问题的快照。请指导我该怎么办？它对我来说看起来像一个网格。
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)
答案 0 :(得分：5)
可能你的内存很糟糕，你不应该写东西（例如，由于缓冲区溢出）。
如果您想知道缓冲区溢出如何导致“无效空闲”错误，请考虑以下示例。
假设您动态分配了10个字节的数组A，然后是结构B。
C运行时通常会在地址返回给用户之前放置有关malloc / new释放的已分配内存块的信息，因此很容易在自由调用时恢复大小。
现在，假设您搞乱了数组下标并执行A [11] =值。您的值将被放置在C运行时保留的字段中以存储上述信息，从而使它们变得毫无意义，因此C运行时将捕获尝试释放B并中止执行的错误。
由于您使用的是Linux，因此可以使用Valgrind来追踪问题并将其排除。
答案 1 :(得分：0)
错误消息表示glibc检测到内存损坏，这很糟糕。 sendip程序可能存在错误。例如，它可能在错误的时间free()内存，或多次，或者可能有一个迷路指针。
我建议您向sendip的作者报告此错误。向他们发送所有这些信息。
我还建议您查看其开发人员提供的sendip的最新版本，并尝试从其最新的源代码副本进行编译。最新版本可能修复了这个错误。
如果您想尝试进一步排查问题，建议您在sendip下运行valgrind命令行，然后在此处剪切并粘贴结果并将其报告给{{1}的开发人员}}。如果您为sendip安装了调试符号，或者在启用了调试符号的情况下从源代码重新编译它，这也会有所帮助。
答案 2 :(得分：0)
valgrind输出指向你正确的错误：
==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)
这是违规写入时的堆栈跟踪。 memcpy只是做了它所说的，所以错误在do_opt，在esp.c的第113行。根据优化情况，您可能会或可能不会在那里找到对memcpy的调用，但该区域中的某些内容正在尝试将内存块复制到错误的位置。在计算副本的目标地址时，错误的根本原因可能略高于此。
==12444== Address 0x41cec5c is 5 bytes after a block of size 23 alloc'd
这描述了程序试图编写的 where 它应该没有。 “[malloced block]之后的5个字节”正是那种导致glibc的malloc原始错误消息的错误写入，它将（某些）内部数据结构放入为应用程序使用分配的内存块之间。 / p>
顺便提一下，数字12444只是程序的进程ID - 如果你在valgrind下运行调用fork的东西，它会很有用，但是否则可以忽略。