Re: FreeBSD crushtool crashing while checking a crushmap

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

On 8-2-2016 12:01, Willem Jan Withagen 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@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?

Not sure if I reported back, but the PULL fixed the issue.

--WjW