2010-02-11 92 views
0

任何人都可以請幫我理解這個錯誤信息嗎?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] 

此外,在尋找與廣發行核心轉儲我得到以下信息:

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<float>::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<float> >::_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<float> > > >::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<float> > >, std::_Select1st<std::pair<std::string const, std::vector<float, std::allocator<float> > > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::vector<float, std::allocator<float> > > > >::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<float> > >, std::_Select1st<std::pair<std::string const, std::vector<float, std::allocator<float> > > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::vector<float, std::allocator<float> > > > >::_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<float> > >, std::_Select1st<std::pair<std::string const, std::vector<float, std::allocator<float> > > >, std::less<std::string>, std::allocator<std::pair<std::string const, std::vector<float, std::allocator<float> > > > >::_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輸入命令 「幀15」 我得到:

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

任何人都可以幫我解決這個問題嗎?

非常感謝。

回答

2

看起來您正在編寫的代碼(?)會嘗試訪問您無權訪問的內存。

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

並可根據您的GDB輸出你也許試圖關閉沒有打開,或者可能已經關閉的文件,因爲在它的範圍不是更多?沒有看到你的代碼,我很難說。

2

它看起來像你打電話給刪除或免費的東西已被刪除或無效/損壞。

嘗試在valgrind下運行,如果原因在您已有的堆棧跟蹤中不明顯。

0

根據我的經驗,有時候,不能解決每個依賴項的makefile(例如,條目不依賴頭文件的排序)會導致加密問題,也就是說可能會更改類簽名,而不是重新編譯所有內容這取決於那個班,導致許多種記憶麻煩。

那麼,也許乾淨和重新編譯?

0

std :: map的dtor在關閉時崩潰。你是否以一種可能破壞其內部狀態的無效方式填充地圖?

+0

我不這麼認爲......這可能是由於內存耗盡造成的嗎?可能是因爲虛擬內存耗盡? – assassin 2010-02-12 05:32:35