On Mon, Feb 8, 2016 at 7:01 PM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote: > On 8-2-2016 06:53, kefu chai wrote: >> >> sorry, just sent an out-dated reply. >> >> On Sun, Feb 7, 2016 at 6:12 AM, Willem Jan Withagen <wjw@xxxxxxxxxxx> >> wrote: >>> >>> Hi, >>> >>> While running run-cli-tests one of the tests dumps while checking if the >>> previous command has build the correct crushmap. >>> I've verified the actual crushmap against one build on CentOS, and they >>> are byte for byte equal. >>> >>> Before I rebased (from beginning of januari) all these tests completed >>> just fine. >>> >>> During checking I get the following dump: >>> >>> # src/crushtool -i >>> src/tes/cli/crushtool/check-overlapped-rules.crushmap.ref --check >>> Assertion failed: (this->_map.find(inter_val) == this->_map.end()), >>> function gap_insert, file >>> /usr/local/include/boost/icl/interval_base_map.hpp, line 555. >>> *** Caught signal (Abort trap) ** >>> in thread 803e15000 >>> ceph version Development (no_version) >>> 1: 0x86f865 <_ZN4ceph9BackTraceC2Ei+0x35> at >>> /usr/srcs/Ceph/work/ceph/src/crushtool >>> 2: 0x86e5f9 <_ZL19handle_fatal_signali+0xa9> at >>> /usr/srcs/Ceph/work/ceph/src/crushtool >>> 3: 0x801811c7d <pthread_sigmask+0x50d> at /lib/libthr.so.3 >>> 4: 0x8018112b2 <pthread_getspecific+0xe22> at /lib/libthr.so.3 >>> 2016-02-06 22:55:09.075189 803e15000 -1 >>> >>> Deleted remainder of the output.... >>> >>> And I appreciate any pointers in helping me debugging this. >> >> >> hey Willem, thanks for looking into this. turns out this is a known issue >> of >> boost 1.55. just posted a pull request to workaround it at >> https://github.com/ceph/ceph/pull/7560. >> >> also did i create a minimal reproducer, it can help with reproducing this >> issue and verify the fix. >> >> you can compile it using: >> >> $ clang++ -std=c++11 -O0 -g test.cc -lm -o test >> > > pffh, > > That's a relieve, since I would otherwise be quite a chase.... > and yes, I'm still at boost 1.55. > > Perhaps in the test check-overlapped-rules.t an extra test: > cmp "$TESTDIR/check-overlapped-rules.crushmap" > "$TESTDIR/check-overlapped-rules.crushmap.ref" we have compile-decompile-recompile.t for testing this. > > Which will at least tell you that the output was consistent with what sould > be there. > And it'll pin-point the source of the error perhaps a bit better. > > Can I just "accept" a pull request in my fork without running into trouble > when I rebase? i don't think you can. rebase against the master is the way to go, i guess. > > --WjW > -- Regards Kefu Chai -- 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
