*** glibc detected *** sendip: free(): invalid next size (normal): 0x09da25e8 *** [duplicate]

This question already has answers here: Closed 11 years ago.

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-0开发者_JS百科ubuntu13) 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.

---

The error message means that glibc has detected memory corruption, which is bad. The sendip program may have a bug. For instance, it may be free()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 sendip command line under valgrind, and then cut-and-paste the results here and report them to the developers of sendip. It would also help if you installed debugging symbols for sendip, or recompiled it from source with debugging symbols enabled.

---

The valgrind output is pointing you right at the bug:

==12444== Invalid write of size 1

The program wrote to memory that it shouldn't have.

==12444==    at 0x4027F40: memcpy (mc_replace_strmem.c:635)
==12444==    by 0x4032269: do_opt (esp.c:113)
==12444==    by 0x804A51D: main (sendip.c:575)

This is a stack trace at the point of the offending write. memcpy just does what it's told, so the fault is in do_opt, at line 113 of esp.c. Depending on optimization, you may or may not find a call to memcpy there, 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.

==12444==  Address 0x41cec5c is 5 bytes after a block of size 23 alloc'd

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 fork under valgrind, but otherwise can be ignored.