*** обнаружен glibc *** sendip: free(): неверный следующий размер (нормальный): 0x09da25e8 ***
Возможный дубликат:
Ошибка C++: free(): неверный следующий размер (быстрый):
Это вопрос C++ (хотя и вопрос "C++ злоупотребляют"). Альтернативный дубликат: Обнаружена ошибка: glibc обнаружил, что неверный следующий размер неверен (быстро)
Я использую инструмент Linux, чтобы генерировать некоторый н / ж трафик, но получаю эту ошибку, когда я пытаюсь отправить данные больше некоторой длины, в то время как инструмент имеет для этого условия.
Весь мой проект застрял между ними. Как я не создал инструмент, поэтому не уверен, где именно происходит ошибка... и эта ошибка (даже 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
...
Это инструмент openip с открытым исходным кодом, и я пытаюсь генерировать трафик ipsec. Если потребуется какая-то часть кода, я добавлю ее сюда, но у меня нет времени сообщать об ошибке и ждать, пока она будет исправлена, потому что в соотв. в соответствии со спецификациями инструмента, я выбрал его для своих целей, и теперь я полностью застрял между ними. Пожалуйста, ведите меня к этому.
Я знаю, что почти невозможно сказать, что это за ошибка и где она, даже не глядя на код. Я просто прошу вашей помощи и предложения, что мне делать в этой ситуации, потому что это даже не моя ошибка.
Если кто-нибудь может сказать мне любой инструмент, который мог бы сказать мне, где именно проблема?
Я даже не уверен, подходит ли этот вопрос здесь; если нет подскажите пожалуйста куда его перенести?
Как предположил я попробовал с 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)
3 ответа
Возможно, вы плохо запутались с памятью, записывая вещи там, где не должны (например, из-за переполнения буфера).
Если вам интересно, как переполнение буфера может вызвать ошибку "недопустимо свободна", рассмотрите следующий пример.
Предположим, вы динамически выделили массив A размером 10 байт, а затем структуру B.
Среда выполнения C обычно размещает информацию о выделенных порциях памяти, освобожденных malloc/new непосредственно перед возвращением пользователю адреса, поэтому легко вернуть размер при свободном вызове.
Теперь предположим, что вы связываетесь с индексами массива и делаете A[11] = значение. Ваше значение будет помещено в поле, зарезервированное средой выполнения C для хранения вышеупомянутой информации, что сделает их бессмысленными, поэтому среда выполнения C обнаружит ошибку, пытаясь освободить B и прервать выполнение.
Поскольку вы работаете в Linux, вы можете использовать Valgrind, чтобы отследить проблему и устранить ее.
Вывод 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в строке 113 esp.c. В зависимости от оптимизации, вы можете или не можете найти звонок memcpy там, но что-то в этой области пытается скопировать блок памяти в неправильное место. Основная причина ошибки, вероятно, будет немного выше, при расчете адреса назначения для копии.
==12444== Address 0x41cec5c is 5 bytes after a block of size 23 alloc'd
Это описывает, где программа пыталась написать, чего не должно было быть. "5 байт после [malloced block]" - это именно тот тип плохой записи, который вызвал бы исходное сообщение об ошибке из malloc glibc, который помещает (некоторые из) его внутренних структур данных между блоками памяти, выделенными для использования приложением.
Кстати, номер 12444 - это просто идентификатор процесса программы - это полезно, если вы запускаете что-то, что вызывает fork под Valgrind, но в противном случае может быть проигнорировано.
Сообщение об ошибке означает, что glibc обнаружил повреждение памяти, что плохо. sendip В программе может быть ошибка. Например, это может быть free()Память в неправильное время, или несколько раз, или может быть ошибочный указатель.
Я предлагаю вам сообщить об этой ошибке авторам sendip, Отправьте им всю эту информацию.
Я также предлагаю вам проверить, какая последняя версия sendip, доступный от его разработчиков, и попробуйте скомпилировать их последнюю версию исходного кода. Возможно, последняя версия исправляет эту ошибку.
Если вы хотите попробовать устранить неполадки, я предлагаю запустить sendip командная строка под valgrindа затем вырезать и вставлять результаты здесь и сообщать о них разработчикам sendip, Также было бы полезно, если бы вы установили символы отладки для sendipили перекомпилировать его из источника с включенными символами отладки.