glibc检测到错误
任何人都可以帮我理解这个错误信息吗？
*** 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] 这条线特别表明了什么？
/abhik/kprank/kprank_new3_norm 09691000-096d3000 rw-p 09691000 00:00 0 [heap]
另外，在使用gdb查看核心转储时，我收到以下消息：
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
在gdb中输入命令“frame 15”后，我得到：
(gdb) frame 15 #15 0x0000000000404846 in main (ac=4, av=0x7fff93a31d48) at kprank_new3_norm.cpp:577 577 fout3.close();
任何人都可以帮我理解这个吗？
非常感谢。
您正在编写的代码（？）似乎试图访问您无权访问的内存。
./kprank_new3_norm: munmap_chunk(): invalid pointer: 0x00000000096912d0 ***
根据您的GDB输出，您可能正在尝试关闭一个未打开的文件，或者由于它不再在范围内而已经关闭的文件？ 没有看到你的代码，我很难说。
看起来你正在调用删除或释放已经被删除或无效/损坏的东西。
尝试在valgrind下运行，如果原因在您已有的堆栈跟踪中不明显。
根据我的经验，有时，不解析每个依赖项的makefile（例如条目不依赖于头文件的那些）可能会导致加密问题，即可能会更改类签名而不会重新编译依赖于此的所有内容上课，导致很多种内存麻烦。
那么，也许干净并重新编译？
std :: map的dtor在关闭时崩溃。 你是否以一种可能破坏其内部状态的无效方式填充地图？