> I have a piece of code that actually seem to crash because the vptr is
> not set:
> (gdb) p *_raw
> $2 = {_vptr$raw = 0x0, data = 0x10cc000 "\003", len = 72, nref = {val =
> 1}, crc_spinlock = 0, crc_map = {__tree_ = {
> __begin_node_ = 0x10cc078,
> __pair1_ =
> {<std::__1::__libcpp_compressed_pair_imp<std::__1::__tree_end_node<std::__1::__tree_node_base<void*>*>,
> std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<std::__1::pair<unsigned
> long, unsigned long>, std::__1::pair<unsigned int, unsigned int> >,
> void*> >, 2>> =
> {<std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<std::__1::pair<unsigned
> long, unsigned long>, std::__1::pair<unsigned int, unsigned int> >,
> void*> >> = {<No data fields>}, __first_ = {
> __left_ = 0x0}}, <No data fields>},
>
> The function that crashes:
> char *buffer::ptr::c_str() {
> assert(_raw);
> if (buffer_track_c_str)
> buffer_c_str_accesses.inc();
> char *p = _raw->get_data();
> return p + _off;
> }
>
> And crash is actually on the return line.
>
> Any ideas as how the vptr can be empty?
Now the _vptr$raw point is part of the internal code of the clang class
function table/constructor. Overwriting that means that class-function
references are problematic to say the least. (in this example get_data()).
The major reason why this occurs is because an object is being zeroed in
C-style way: memset( &obj, 0, sizeof(obj))
And thus overwriting the _vptr.
Note that this does not bite the FreeBSD compilation, but also any other
attempts to build Ceph with clang.
Now the strange thing is that this does not bite Clang compilation much
more. But the only test that fails is unittest_denc. So I guess that
most of the code is rather well behaved.
And I'm off on a search to find the culprit.
--WjW
--
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
