erreur détectée par la glibc

Quelqu’un peut-il m’aider à comprendre ce message d’erreur?

*** glibc detected *** ./kprank_new3_norm: munmap_chunk(): invalid pointer: 0x00000000096912d0 *** ======= Backtrace: ========= /lib64/libc.so.6(cfree+0x1b6)[0x3df6e75a36] ./kprank_new3_norm[0x409277] ./kprank_new3_norm[0x4092a9] ./kprank_new3_norm[0x4092ea] ./kprank_new3_norm[0x40941f] ./kprank_new3_norm[0x40943b] ./kprank_new3_norm[0x40945f] ./kprank_new3_norm[0x409628] ./kprank_new3_norm[0x4096a7] ./kprank_new3_norm[0x40968d] ./kprank_new3_norm[0x409750] ./kprank_new3_norm[0x4097a5] ./kprank_new3_norm[0x404846] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3df6e1d974] ./kprank_new3_norm(__gxx_personality_v0+0x99)[0x4017f9] ======= Memory map: ======== 00400000-00412000 r-xp 00000000 08:21 25795429 /home/rkrish/abhik/kprank/kprank_new3_norm 00611000-00612000 rw-p 00011000 08:21 25795429 /home/rkrish/abhik/kprank/kprank_new3_norm 09691000-096d3000 rw-p 09691000 00:00 0 [heap] 3df6a00000-3df6a1c000 r-xp 00000000 08:02 3388079 /lib64/ld-2.5.so 3df6c1b000-3df6c1c000 r--p 0001b000 08:02 3388079 /lib64/ld-2.5.so 3df6c1c000-3df6c1d000 rw-p 0001c000 08:02 3388079 /lib64/ld-2.5.so 3df6e00000-3df6f4c000 r-xp 00000000 08:02 3388111 /lib64/libc-2.5.so 3df6f4c000-3df714c000 ---p 0014c000 08:02 3388111 /lib64/libc-2.5.so 3df714c000-3df7150000 r--p 0014c000 08:02 3388111 /lib64/libc-2.5.so 3df7150000-3df7151000 rw-p 00150000 08:02 3388111 /lib64/libc-2.5.so 3df7151000-3df7156000 rw-p 3df7151000 00:00 0 3df7200000-3df7282000 r-xp 00000000 08:02 3388796 /lib64/libm-2.5.so 3df7282000-3df7481000 ---p 00082000 08:02 3388796 /lib64/libm-2.5.so 3df7481000-3df7482000 r--p 00081000 08:02 3388796 /lib64/libm-2.5.so 3df7482000-3df7483000 rw-p 00082000 08:02 3388796 /lib64/libm-2.5.so 3e05000000-3e0500d000 r-xp 00000000 08:02 3388776 /lib64/libgcc_s-4.1.2-20080825.so.1 3e0500d000-3e0520d000 ---p 0000d000 08:02 3388776 /lib64/libgcc_s-4.1.2-20080825.so.1 3e0520d000-3e0520e000 rw-p 0000d000 08:02 3388776 /lib64/libgcc_s-4.1.2-20080825.so.1 3e09400000-3e094e6000 r-xp 00000000 08:02 796282 /usr/lib64/libstdc++.so.6.0.8 3e094e6000-3e096e5000 ---p 000e6000 08:02 796282 /usr/lib64/libstdc++.so.6.0.8 3e096e5000-3e096eb000 r--p 000e5000 08:02 796282 /usr/lib64/libstdc++.so.6.0.8 3e096eb000-3e096ee000 rw-p 000eb000 08:02 796282 /usr/lib64/libstdc++.so.6.0.8 3e096ee000-3e09700000 rw-p 3e096ee000 00:00 0 2b3517077000-2b3517078000 rw-p 2b3517077000 00:00 0 2b3517079000-2b351707d000 rw-p 2b3517079000 00:00 0 2b3517093000-2b3517096000 rw-p 2b3517093000 00:00 0 7fff93a1e000-7fff93a33000 rw-p 7ffffffea000 00:00 0 [stack] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] 

Qu’est-ce que cette ligne indique particulièrement?

 /abhik/kprank/kprank_new3_norm 09691000-096d3000 rw-p 09691000 00:00 0 [heap] 

De plus, en regardant le core dump avec gdb, je reçois le message suivant:

 Core was generated by `./kprank_new3_norm 2 5 3'. Program terminated with signal 6, Aborted. [New process 8377] #0 0x0000003df6e30215 in raise () from /lib64/libc.so.6 (gdb) backtrace #0 0x0000003df6e30215 in raise () from /lib64/libc.so.6 #1 0x0000003df6e31cc0 in abort () from /lib64/libc.so.6 #2 0x0000003df6e6a7fb in __libc_message () from /lib64/libc.so.6 #3 0x0000003df6e75a36 in free () from /lib64/libc.so.6 #4 0x0000000000409277 in __gnu_cxx::new_allocator::deallocate (this=0x96911c8, __p=0x96912d0) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/ext/new_allocator.h:94 #5 0x00000000004092a9 in std::_Vector_base<float, std::allocator >::_M_deallocate (this=0x96911c8, __p=0x96912d0, __n=2) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:133 #6 0x00000000004092ea in ~_Vector_base (this=0x96911c8) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:119 #7 0x000000000040941f in ~vector (this=0x96911c8) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:272 #8 0x000000000040943b in ~pair (this=0x96911c0) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_pair.h:69 #9 0x000000000040945f in __gnu_cxx::new_allocator<std::pair<std::string const, std::vector<float, std::allocator > > >::destroy (this=0x7fff93a30997, __p=0x96911c0) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/ext/new_allocator.h:107 #10 0x0000000000409628 in std::_Rb_tree<std::string, std::pair<std::string const, std::vector<float, std::allocator > >, std::_Select1st<std::pair<std::string const, std::vector<float, std::allocator > > >, std::less, std::allocator<std::pair<std::string const, std::vector<float, std::allocator > > > >::destroy_node (this=0x7fff93a31680, __p=0x96911a0) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:391 #11 0x00000000004096a7 in std::_Rb_tree<std::string, std::pair<std::string const, std::vector<float, std::allocator > >, std::_Select1st<std::pair<std::string const, std::vector<float, std::allocator > > >, std::less, std::allocator<std::pair<std::string const, std::vector<float, std::allocator > > > >::_M_erase (this=0x7fff93a31680, __x=0x96911a0) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:1266 #12 0x000000000040968d in std::_Rb_tree<std::string, std::pair<std::string const, std::vector<float, std::allocator > >, std::_Select1st<std::pair<std::string const, std::vector<float, std::allocator > > >, std::less, std::allocator<std::pair<std::string const, std::vector<float, std::allocator > > > >::_M_erase (this=0x7fff93a31680, __x=0x9691100) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:1264 #13 0x0000000000409750 in ~_Rb_tree (this=0x7fff93a31680) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:578 #14 0x00000000004097a5 in ~map (this=0x7fff93a31680) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_map.h:93 #15 0x0000000000404846 in main (ac=4, av=0x7fff93a31d48) at kprank_new3_norm.cpp:577 

En entrant la commande “frame 15” dans gdb je reçois:

 (gdb) frame 15 #15 0x0000000000404846 in main (ac=4, av=0x7fff93a31d48) at kprank_new3_norm.cpp:577 577 fout3.close(); 

Quelqu’un peut-il m’aider s’il vous plaît à donner un sens à cela?

Merci beaucoup les gens.

Il semble que le code que vous écrivez (?) Tente d’accéder à la mémoire pour laquelle vous ne possédez pas les droits.

 ./kprank_new3_norm: munmap_chunk(): invalid pointer: 0x00000000096912d0 *** 

Et en fonction de votre sortie GDB, vous essayez peut-être de fermer un fichier qui n’était pas ouvert ou qui est peut-être déjà fermé car il n’est plus dans la scope? C’est difficile pour moi de dire sans voir votre code.

Il semble que vous appeliez delete ou free sur quelque chose qui a déjà été supprimé ou qui est invalide / corrompu.

Essayez d’exécuter sous valgrind si la cause de la stack que vous avez déjà ne permet pas d’en déterminer la cause.

D’après mon expérience, parfois, les makefiles qui ne résolvent pas chaque dépendance (par exemple, ceux du type où les entrées ne dépendent pas des fichiers d’en-tête) peuvent causer des problèmes de chiffrement, c’est-à-dire que l’on peut changer les signatures de classe sans recomstackr tout classe, entraînant de nombreuses sortes de problèmes de mémoire.

Alors, peut-être nettoyer et recomstackr?

Le dtor de std :: map se plante à l’arrêt. Avez-vous rempli la carte d’une manière non valide qui aurait pu corrompre son état interne?