On Tuesday, May 22, 2012 at 3:12 AM, Felix Feinhals wrote: > I am not quite sure on how to get you the coredump infos. I installed > all ceph-dbg packages and executed: > > gdb /usr/bin/ceph-mds core > > snip > > GNU gdb (GDB) 7.0.1-debian > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /usr/bin/ceph-mds...Reading symbols from > /usr/lib/debug/usr/bin/ceph-mds...done. > (no debugging symbols found)...done. > [New Thread 22980] > [New Thread 22984] > [New Thread 22986] > [New Thread 22979] > [New Thread 22970] > [New Thread 22981] > [New Thread 22971] > [New Thread 22976] > [New Thread 22973] > [New Thread 22975] > [New Thread 22974] > [New Thread 22972] > [New Thread 22978] > [New Thread 22982] > > warning: Can't read pathname for load map: Input/output error. > Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done. > Loaded symbols for /lib/libpthread.so.0 > Reading symbols from /usr/lib/libcrypto++.so.8...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libcrypto++.so.8 > Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib/libuuid.so.1 > Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib/librt.so.1 > Reading symbols from /usr/lib/libtcmalloc.so.0...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libtcmalloc.so.0 > Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libstdc++.so.6 > Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. > Loaded symbols for /lib/libm.so.6 > Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. > Loaded symbols for /lib/libgcc_s.so.1 > Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. > Loaded symbols for /lib/libc.so.6 > Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging > symbols found)...done. > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > Reading symbols from /usr/lib/libunwind.so.7...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib/libunwind.so.7 > Core was generated by `/usr/bin/ceph-mds -i c --pid-file > /var/run/ceph/mds.c.pid -c /etc/ceph/ceph.con'. > Program terminated with signal 11, Segmentation fault. > #0 0x00007f10c00d2ebb in raise () from /lib/libpthread.so.0 > Argh. This is finicky and annoying; don't feel bad. :) There are two possibilities here: 1) If I remember correctly, PATH and the actual debug symbol install locations often don't match up. Check out where the debug packages actually installed to, and make sure that directory is in PATH when running gdb. 2) The default thread you're getting a backtrace on doesn't look to be the one we actually care about (notice how the backtrace is through completely different parts of the code); it's conceivable that there just aren't any debug symbols for those libraries. Try running "thread apply all bt" (I think that's the right command) and looking for one that matches the backtrace in the log file. Then switch to it ("thread x" where x is the thread number) and get the backtrace of that. -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
