*** glibc détecté *** sendip: free(): invalid suivant la taille (normal): 0x09da25e8 *** [en double]
Double Possible:
C++ Erreur: free(): invalid suivant la taille (rapide):
C'est une question C++ (bien qu'une question 'C++ soit abusée'). Alternative dupliquer: face à une erreur: glibc détecté libre invalide next size (fast)
j'utilise un Outil Linux pour générer du trafic n / w, mais en obtenant cette erreur lorsque j'essaie d'envoyer des données d'une longueur supérieure à une certaine tandis que l'outil a prévu pour cela.
tout mon projet est resté entre les deux. Comme je n'ai pas créé l'outil donc pas sûr où exactement est l'erreur se produit... et cette erreur (même gdb ) ne donne aucune indication quant à l'endroit où se trouve le problème.Comment détecter le moment de l'erreur?
je donne quelques instantanés du problème si ils aident. Merci de me guider comment dois-je procéder? Ça ressemble à un filet pour moi.
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
ma version glibc ..
udit@udit-Dabba ~/Downloads/sendip-2.5-mec-2 $ ldd --version
ldd (Ubuntu EGLIBC 2.13-0ubuntu13) 2.13
...
c'est un outil open source sendip et j'essaie de générer du trafic ipsec. Si une partie de code est nécessaire, je l'ajouterai ici, mais je n'ai pas le temps de signaler le bogue et d'attendre qu'il soit corrigé car acc. aux spécifications de l'outil je le choisis pour mon but et maintenant je suis complètement coincé entre. Merci de me guider pour cette.
je sais qu'il est presque impossible de dire ce qu'est l'erreur et où elle se trouve sans même regarder le code. Je demande simplement votre aide et vos suggestions sur ce que je dois faire dans cette situation parce que ce n'est même pas complètement mon erreur.
si quelqu'un pouvait me dire n'importe quel outil qui pourrait me dire exactement où est le problème ????
Je ne suis même pas sûr si la question Est adapté pour ici; sinon s'il vous plaît me dire où le migrer?
comme suggéré j'ai essayé avec valgrind . Je n'ai même jamais entendu parler avant, donc aucune idée de la façon de procéder ici à la sortie. S'il vous plaît guidez-moi comment aller plus loin?
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 réponses
probablement que vous avez gravement altéré la mémoire, écrivant des choses où vous ne devriez pas (par exemple, en raison de débordements de tampon).
si vous vous demandez comment un débordement de tampon peut causer une erreur" libre " invalide, alors considérez l'exemple suivant.
supposons que vous ayez affecté dynamiquement un tableau A de 10 octets, puis une structure B.
c runtimes place habituellement des informations sur les morceaux de mémoire alloués libérés par malloc / nouveau juste avant l'adresse retournée à l'utilisateur, il est donc facile de récupérer la taille à l'invocation gratuite.
maintenant, supposez que vous vous trompez avec les indices de tableau et faites un[11] = valeur. Votre valeur sera placée dans le champ réservé par le C runtime pour stocker les informations susmentionnées, les rendant sans signification, de sorte que le C runtime attrapera l'erreur en essayant de libérer B et d'annuler l'exécution.
puisque vous êtes sous Linux, vous pouvez utiliser Valgrind afin de traquer le problème et l'éliminer.
le message d'erreur signifie que glibc a détecté une corruption de la mémoire, qui est mauvaise. Le programme sendip peut avoir un bug. Par exemple, il peut être free() mémoire ing au mauvais moment, ou plusieurs fois, ou il peut y avoir un pointeur errant.
je vous suggère de signaler ce bug aux auteurs de sendip . Envoyer toutes ces informations.
je vous suggère aussi de vérifier quelle est la dernière version de sendip , disponible auprès de ses développeurs, et essayez de compiler à partir de leur dernière copie du code source. Il est possible que la dernière version corrige ce bug.
si vous voulez essayer de résoudre plus loin, je suggère d'exécuter votre ligne de commande sendip sous valgrind , puis couper-coller les résultats ici et les rapporter aux développeurs de sendip . Il serait également utile si vous installez des symboles de débogage pour sendip , ou si vous les recompilez à partir de la source avec les symboles de débogage activé.
la sortie valgrind vous pointe droit sur le bug:
==12444== Invalid write of size 1
le programme a écrit à la mémoire qu'il n'aurait pas dû.
==12444== at 0x4027F40: memcpy (mc_replace_strmem.c:635)
==12444== by 0x4032269: do_opt (esp.c:113)
==12444== by 0x804A51D: main (sendip.c:575)
c'est une trace de pile au point de l'écriture incriminée. memcpy fait juste ce qu'on lui dit, donc la faute est dans do_opt , à la ligne 113 de esp.C. Selon l'optimisation, vous pouvez ou non Trouver un appel à memcpy là, mais quelque chose dans cette zone essaie de copier un bloc de mémoire dans le mauvais endroit. La cause fondamentale du bogue est probablement un peu au-dessus de cela, dans le calcul de l'adresse de destination de la copie.
==12444== Address 0x41cec5c is 5 bytes after a block of size 23 alloc'd
décrit où le programme a essayé d'écrire qu'il n'aurait pas dû. "5 octets après un [malloced bloc]" est exactement le genre de mauvaise écriture qui provoque le message d'erreur d'origine de la glibc malloc, qui met de (certains de) ses données internes structures entre les blocs de mémoire alloués pour l'utilisation de l'application.
soit dit en passant, le numéro 12444 est juste L'identifiant du processus du programme - c'est utile si vous exécutez quelque chose qui appelle fork sous valgrind, mais autrement peut être ignoré.