Bug #43376
closed
crimson::dmclock Assertion '__builtin_expect(__n < this->size(), true)' failed.
Added by Samuel Just over 4 years ago.
Updated over 4 years ago.
Description
sage-2019-12-16_15:01:24-rados-wip-sage3-testing-2019-12-13-1721-distro-basic-smithi
It's a bug with dmclock/support/src/indirect_intrusive_heap.h. Centos 8 seems to make it reproduce frequently.
[ RUN ] IndIntruHeap.remove_greatest
/usr/include/c++/8/bits/stl_vector.h:932: std::vector<_Tp, Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = std::shared_ptr<Elem>; _Alloc = std::allocator<std::shared_ptr<Elem> >; std::vector<_Tp, _Alloc>::reference = std::shared_ptr<Elem>&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '_builtin_expect(__n < this->size(), true)' failed.
[1] 17354 abort (core dumped) ./bin/dmclock-data-struct-tests
centos 8 picked up a version of glibc++ with new vector checks. Our rpm packages happen to build with -D_GLIBCXX_ASSERTIONS which enable them. indirect_intrusive_heap.h has an overindex bug when removing the greatest element which is often harmless (and hence hasn't triggered this in the past) but does run afoul of the assert. Have unit test, testing fix.
- Related to Bug #43394: crimson::dmclock segv in crimson::IndIntruHeap added
I think it's reasonably safe to assume this and #43394 are related? If not I apologise,
- Status changed from New to In Progress
- Status changed from In Progress to Resolved
Should be fixed with PR #32380 2c9542901532feafd569d92e9f67ccd2e1af3129
Also available in: Atom
PDF