Glibc detected *** sendip: free(): invalid next size (normal): 0x09da25e8 *** [closed]?

Up vote 1 down vote favorite share g+ share fb share tw.

Possible Duplicate: C++ Error: 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 occuring... 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?

Its 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" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so.6(+0x6b961)0x17b961 /lib/i386-linux-gnu/libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so.6(+0x6d28b)0x17d28b /lib/i386-linux-gnu/libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so.6(cfree+0x6d)0x18041d /lib/i386-linux-gnu/libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so.6(fclose+0x14a)0x16b9ca /lib/i386-linux-gnu/libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so.6(+0xe053f)0x1f053f /lib/i386-linux-gnu/libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so.6(__res_ninit+0x25)0x1f0815 /lib/i386-linux-gnu/libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so.6(__res_maybe_init+0x130)0x1f1810 /lib/i386-linux-gnu/libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so.6(__nss_hostname_digits_dots+0x34)0x1f37d4 /lib/i386-linux-gnu/libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">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" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so" rel="nofollow">libc.so.6(__libc_start_main+0xe7)0x126e37 sendip0x8048f81 ======= 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 ... its 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 its 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 t migrate it?

As suggeted 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) 202.13, 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) c glibc link|improve this question edited 2.137 at 0:18 asked 2.138 at 22:48Udit Gupta3691217 100% accept rate.

Okkkkkk......now its working it was missing a package libgc I have installed it and it is working fine. But that too suggested by valgrind. – Udit Gupta Oct 5 '11 at 0:56.

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 A11 = 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.

Wow.......its running but what is surprising to me is that when I tried to run valgrind,it did not run at its first go.it told me to install libgc first. After I installed it and run the valgrind the following output appears. But now the command started working properly what is this magic?

And also valgrind shows no error now . – Udit Gupta Oct 5 '11 at 0:42 I am unfamiliar with libgc, and my copy of valgrind has never asked me to do that. However, it's quite possible that installing it perturbed your execution environment and hid the bug -- try removing it again.

– Zack Oct 5 '11 at 2:22.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.