Re: FreeBSD crushtool crashing while checking a crushmap

[Willem Jan Withagen <wjw@digiware.nl>]

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@digiware.nl> 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"

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?

--WjW