*** glibc的检测*** sendip:免费():无效的下一个尺寸(标准):0x09da25e8 *** [英] *** glibc detected *** sendip: free(): invalid next size (normal): 0x09da25e8 ***

查看:295
本文介绍了*** glibc的检测*** sendip:免费():无效的下一个尺寸(标准):0x09da25e8 ***的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述


  

可能重复:结果
   C ++错误:免费():无效的下一个尺寸(快):


这是一个C ++的问题(尽管是C ++被滥用的问题)。替代重复的:<一href=\"http://stackoverflow.com/questions/2317021/facing-an-error-glibc-detected-free-invalid-next-size-fast\">Facing错误:glibc的免费检测无效的下一个尺寸(快)


我使用Linux工具生成一些N / W流量,但得到这个错误,当我尝试发送更大的数据比一些长而工具有规定的。

我的整个项目已夹在其间。由于我没有创造的工具,所以不知道究竟哪里发生错误...这错误(甚至 GDB )是不是给有关问题出在哪里任何暗示。如何检测错误点?

我给这个问题的一些快照,如果他们提供帮助。请指导我应该如何进行?它看起来像一个网格在我身上。

  udit @ udit-Dabba〜$ sendip -v -p -f命令ipv6 file.txt的-6S :: 1 -p ESP -es 0x20的当量0X40 -ei
ABCD -ei ZXC -p tcp的-ts 21 -td 21 :: 2 |更多
*** glibc的检测*** sendip:免费():无效的下一个尺寸(标准):0x09da25e8 ***
=======回溯:=========
/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(主+ 0x8eb)0x804a635]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x126e37]
sendip [0x8048f81]
=======存储器映射:========
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.so005fd000-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.so00837000-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.100fb3000-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堆]
b7600000-RW b7621000-P 00000000 00:00 0
b7621000-b7700000 --- p 00000000 00:00 0
b77ce000-RW b77d0000-P 00000000 00:00 0
b77e1000-RW b77e2000-P 00000000 00:00 0
b77e2000-b77e3000 - [R - S 00000000 08:07 3148711 /home/udit/file.txt
b77e3000-RW b77e5000-P 00000000 00:00 0
bfb5a000-RW bfb7b000-P 00000000 00:00 0 [堆栈]
ESP
新增43选项
初始化模块的IPv6
初始化模块ESP
初始化模块TCP

我的glibc的版本。

  udit @ udit-Dabba〜/下载/ sendip-2.5-MEC-2 $ LDD --version
LDD(Ubuntu的EGLIBC 2.13-0ubuntu13)2.13
 ...

这是一个开源工具sendip,我试图生成IPSec流量。如果有任何code部分将被要求我将其添加在这里,但没有及时报告的bug,并等待它是固定的,因为累计。到刀具规格我选择它为我的目的,现在我完全卡在中间。请指导我的。

我知道这几乎是不可能告诉什么是错误,它在哪里,甚至没有看code。我只是要求你的帮助和建议我应该在这种情况下做的,因为它不是甚至完全我的错。

如果有人能告诉我任何工具,它可以告诉我在哪里,问题究竟出在????

我什至不知道这个问题是否适合在这里;如果不是,请告诉我在哪里迁移呢?

的建议我试着用的valgrind 。我从来没有听说这件事之前,所以不知道如何与这里进行的是输出。请指导我如何去做进一步的?

  udit @ udit-Dabba〜$的valgrind --leak检查= YES sendip -v -p的IPv6
 -f file.txt的-6S :: 1 -p ESP -es 0x20的当量0X40 -ei ABCD -ei ZXC
 -p tcp的-ts 21 -td 21:2 == == 12444 MEMCHECK,内存错误检测
 == == 12444版权所有(C)2002-2010,和GNU GPL的,Julian Seward写等。
 == == 12444 Valgrind的使用,3.6.1和LibVEX;与-h版权信息重新运行
 == == 12444命令:sendip -v -p -f命令ipv6 file.txt的-6S :: 1 -p ESP
-es 0x20的当量0X40 -ei ABCD -ei ZXC -p tcp的-ts 21 -td 21:2
 == == 12444
 ESP
 新增43选项
 初始化模块的IPv6
 初始化模块ESP
 初始化模块TCP
 == == 12444大小为1的写入无效
 == == 12444在0x4027F40:的memcpy(mc_replace_strmem.c:635)
 == == 12444通过0x4032269:do_opt(esp.c:113)
 == == 12444通过0x804A51D:主(sendip.c:575)
 == == 12444地址0x41cec5c是大小23 alloc'd块后5个字节
 == == 12444在0x402699A:realloc的(vg_replace_malloc.c:525)
 == == 12444通过0x4032231:do_opt(esp.c:111)
 == == 12444通过0x804A51D:主(sendip.c:575)
== == 12444
最终处理模块TCP
敲定模块ESP
最终处理模块的IPv6
最后的分组数据:
60 00 00 00`...
00 5B 32 20 [2
/ *其余数据包内容* /
65 66 0A 0A EF ..
00 00 02 06 ....
1E 97 1E ...
无法打开RAW插槽:不允许操作
释放模块的IPv6
释放模块ESP
释放模块TCP
== == 12444
== == 12444 HEAP摘要:
== == 12444在退出,使用:16在1块字节
== == 12444总堆的使用情况:118 allocs,117的FreeS,分配8,236字节
== == 12444
== == 12444在1块16个字节肯定是失去了在负的战绩1 1
== == 12444在0x40268A4:的malloc(vg_replace_malloc.c:236)
== == 12444通过0x4031F47:???
== == 12444通过0x804A34F:主(sendip.c:517​​)
== == 12444
== == 12444泄漏摘要:
== == 12444失去了肯定:16字节1块
== == 12444间接丧失:0字节0块
== == 12444失去了可能:0字节0块
== == 12444尚能访问:0块0字节
== == 12444燮pressed:0字节0块
== == 12444
== == 12444侦测到并SUP pressed错误计数,重新运行:-v
== == 12444错误摘要:从2环境4个错误(SUP pressed:30 11)


解决方案

也许你已经很糟糕记忆混乱,写的东西,你不应该(例如,由于缓冲区溢出)。

如果你想知道一个缓冲区溢出是如何导致无效免费的错误,然后再考虑下面的例子。

假设您已经动态分配的10个字节数组A,然后是B结构。

C运行通常会将有关的malloc /新发布之前的地址返回给用户分配的内存块的信息,所以很容易在自由调用找回大小。

现在,假设你惹数组下标,并做了[11] =价值。您的值将被放置在由C运行时保留存储上述信息的字段中,把它们无意义,所以C运行时将捕获的错误尝试释放B和中止执行

既然你是在Linux上,你可以使用 Valgrind的追查问题和消除它。

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)

解决方案

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:免费():无效的下一个尺寸(标准):0x09da25e8 ***的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆