*** glibc détecté *** sendip: free (): prochaine taille non valide (normal): 0x09da25e8 ***

Dupliquer possible:
Erreur C ++: free (): prochaine taille non valide (rapide):

C’est une question C ++ (bien qu’une question sur les abus de C ++). Doublage alternatif: Face à une erreur: glibc a détecté une taille non valide non valide suivante (rapide)


J’utilise un outil Linux pour générer du trafic n / w, mais cette erreur survient lorsque j’essaie d’envoyer des données d’une longueur supérieure à une certaine longueur alors que l’outil est prévu à cet effet.

Tout mon projet est coincé entre les deux. Comme je n’ai pas créé l’outil, je ne sais donc pas exactement où se produit l’erreur … et cette erreur (même gdb ) ne donne aucune indication quant à la localisation du problème. Comment détecter le point d’erreur?

Je donne quelques instantanés du problème s’ils aident. S’il vous plaît guidez-moi comment dois-je procéder Cela ressemble à un maillage 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 de la 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 du code est requirejse, je l’appendai ici, mais je n’aurai pas le temps de signaler le bogue et d’attendre qu’il soit corrigé. pour les spécifications de l’outil, je l’ai choisi pour mon but et maintenant je suis complètement coincé entre les deux. Veuillez me guider pour cela.

Je sais qu’il est presque impossible de dire quelle 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 devrais faire dans cette situation car ce n’est même pas complètement mon erreur.

Si quelqu’un pouvait me dire un outil qui pourrait me dire où est exactement le problème ????

Je ne suis même pas sûr que la question convienne ici; sinon, s’il vous plaît, dites-moi où migrer?

Comme suggéré, j’ai essayé avec valgrind . Je n’avais même jamais entendu parler de cela auparavant, donc je ne sais pas comment procéder. S’il vous plaît me guider 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) 

Vous avez probablement mal gaché avec la mémoire, écrivant des choses là où vous ne devriez pas (par exemple, en raison de débordements de mémoire tampon).

Si vous vous demandez comment un dépassement de mémoire tampon peut provoquer une erreur “invalide libre”, considérez l’exemple suivant.

Supposons que vous ayez alloué dynamicment un tableau A de 10 octets, puis une structure B.

C runtimes place généralement des informations sur les blocs de mémoire alloués publiés par malloc / new juste avant que l’adresse ne soit renvoyée à l’utilisateur. Il est donc facile de récupérer la taille à l’invocation gratuite.

Maintenant, supposons que vous bousiller avec les indices de tableau et que vous faites A [11] = value. Votre valeur sera placée dans le champ réservé par le runtime C pour stocker les informations susmentionnées, les rendant ainsi inutiles, de sorte que le runtime C captera l’erreur en essayant de libérer B et d’abandonner l’exécution.

Puisque vous êtes sous Linux, vous pouvez utiliser Valgrind pour localiser le problème et l’éliminer.

Le message d’erreur signifie que la glibc a détecté une corruption de mémoire, qui est mauvaise. Le programme sendip peut avoir un bogue. Par exemple, il peut s’agir de free() mémoire au mauvais moment, ou plusieurs fois, ou d’un pointeur parasite.

Je suggère que vous sendip ce bug aux auteurs de sendip . Envoyez-leur toutes ces informations.

Je vous suggère également de vérifier quelle est la dernière version de sendip , disponible auprès de ses développeurs, et d’essayer de comstackr à partir de leur dernière copie du code source. Il est possible que la dernière version corrige ce bogue.

Si vous souhaitez essayer de résoudre davantage de problèmes, je vous suggère d’exécuter votre ligne de commande sendip sous valgrind , puis de copier-coller les résultats ici et de les signaler aux développeurs de sendip . Cela vous aiderait également si vous sendip des symboles de débogage pour sendip ou si vous le recompiliez à partir de la source avec les symboles de débogage activés.

La sortie valgrind vous pointe vers le bogue:

 ==12444== Invalid write of size 1 

Le programme a écrit en 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) 

Il s’agit d’une trace de stack au moment de l’écriture fautive. memcpy juste ce qui est dit, la faute est donc dans do_opt , à la ligne 113 de esp.c. En fonction de l’optimisation, vous pouvez éventuellement trouver un appel à memcpy , mais quelque chose dans cette zone tente de copier un bloc de mémoire au mauvais endroit. La cause première du bogue sera probablement un peu plus haute que cela, dans le calcul de l’adresse de destination pour la copie.

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

Ceci décrit le programme a essayé d’écrire qu’il ne devrait pas l’être. “5 octets après un [bloc mallocé]” est exactement le type d’écriture incorrecte qui provoquerait le message d’erreur d’origine du malloc de glibc, qui met (certaines de ses) ses structures de données internes entre des blocs de mémoire alloués à l’utilisation de l’application.

Incidemment, le numéro 12444 n’est que l’ID de processus du programme – il est utile si vous exécutez quelque chose qui appelle fork sous valgrind, mais qui peut sinon être ignoré.