Ceph

This crash occurred on a non-leader (b) while the leader (a) was experiencing some kind of a memory leak and all mons were showing elevated CPU usage. One of the non-leaders (d) was (and is) falling out of quorum without failing. These issue may be completely unrelated to this crash. Stack trace:

ceph version 0.60-472-g327002e (327002e2526fb7502ef93564af3c9a7da2e95f92)
 1: /usr/bin/ceph-mon() [0x59135a]
 2: (()+0xfcb0) [0x7f96feccccb0]
 3: (gsignal()+0x35) [0x7f96fd424425]
 4: (abort()+0x17b) [0x7f96fd427b8b]
 5: (()+0x7439e) [0x7f96fd46239e]
 6: (()+0x7eb96) [0x7f96fd46cb96]
 7: (std::_Rb_tree<std::string, std::pair<std::string const, ceph_mon_subscribe_item>, std::_Select1st<std::pair<std::string const, ceph_mon_subsc
ribe_item> >, std::less<std::string>, std::allocator<std::pair<std::string const, ceph_mon_subscribe_item> > >::_M_erase(std::_Rb_tree_node<std::p
air<std::string const, ceph_mon_subscribe_item> >*)+0x3c) [0x5f0f6c]
 8: (MMonSubscribe::~MMonSubscribe()+0x25) [0x5f0fd5]
 9: (DispatchQueue::entry()+0x3b4) [0x6ac064]
 10: (DispatchQueue::DispatchThread::entry()+0xd) [0x63a28d]
 11: (()+0x7e9a) [0x7f96fecc4e9a]
 12: (clone()+0x6d) [0x7f96fd4e1cbd]

I will attached the log as an update this afternoon.