glibc detected error

Question

Hey, Can anybody please help me make sense of this error message?

*** 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]

What does this line especially indicate?

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

Also, on looking at the core dump with gdb I get the following message:

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

Upon entering the command "frame 15" in gdb I get:

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

Can anyone please help me out make sense of this?

Thanks a lot people.

Answer 1

It appears that code you are writing(?) tries to access memory you don't have rights to.

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

And based on your GDB output you are maybe trying to close a file that wasn't open, or maybe already closed due to it not being in scope any more? It's hard for me to say without seeing your code.

Answer 2

It looks like you're calling delete or free on something that has either already been deleted or is invalid/corrupt.

Try running under valgrind if the cause isn't apparent from the stack trace you already have.

Answer 3

From my experience, sometimes, makefiles that don't resolve for every dependency (e.g. the ones of the sort where entries do not depend on header files) can cause encrypted trouble, i.e. one might change class signatures and not recompile everything that depends on that class, resulting in many sorts of memory trouble.

So, maybe make clean and recompile?

Answer 4

The dtor of std::map is crashing on shutdown. Did you fill the map in some invalid way that could have corrupted its internal state?