Bug #43376
closedcrimson::dmclock Assertion '__builtin_expect(__n < this->size(), true)' failed.
0%
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.
Updated by Samuel Just over 4 years ago
[ 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.
Updated by Brad Hubbard over 4 years ago
- Related to Bug #43394: crimson::dmclock segv in crimson::IndIntruHeap added
Updated by Brad Hubbard over 4 years ago
I think it's reasonably safe to assume this and #43394 are related? If not I apologise,
Updated by Samuel Just over 4 years ago
- Status changed from In Progress to Resolved
Should be fixed with PR #32380 2c9542901532feafd569d92e9f67ccd2e1af3129