On 23-12-2016 01:19, Brad Hubbard wrote: > Any clue from Valgrind? > > Did you say this only happens with clang or doesn't happen with clang? I have to comment this piece of code to get unittest_denc to pass. And with GCC this does not happen. But I'm not sure how GCC does its class function table stuff. And whether that also involves a vptr? --WjW > On Fri, Dec 23, 2016 at 8:01 AM, Allen Samuels > <Allen.Samuels@xxxxxxxxxxx> wrote: >> I believe I mis-read the data. What I've seen before doesn't fit this data. >> >> If it fails in unit test, it shouldn't be hard to just set a HW breakpoint on the vptr and see who the culprit is. >> >> >> Allen Samuels >> SanDisk |a Western Digital brand >> 2880 Junction Avenue, San Jose, CA 95134 >> T: +1 408 801 7030| M: +1 408 780 6416 >> allen.samuels@xxxxxxxxxxx >> >> >>> -----Original Message----- >>> From: Willem Jan Withagen [mailto:wjw@xxxxxxxxxxx] >>> Sent: Thursday, December 22, 2016 10:37 AM >>> To: Allen Samuels <Allen.Samuels@xxxxxxxxxxx>; Ceph Development >>> <ceph-devel@xxxxxxxxxxxxxxx> >>> Subject: Re: An empty vptr in an raw object >>> >>> On 22-12-2016 19:02, Allen Samuels wrote: >>>> I have seen cases of null vptr due to an incompletely constructed object, >>> i.e., an object that's in the middle of being constructed. >>> >>> I going to believe you right away. >>> But I'm having a hard time imagining such a case. >>> >>> Are you suggesting a object is referenced, whilest it is not yet complete. who >>> does the referencing then? due to threading? >>> That would be even harder to find. >>> >>> --WjW >>> >>> >>>> Allen Samuels >>>> SanDisk |a Western Digital brand >>>> 951 SanDisk Drive, Milpitas, CA 95035 >>>> T: +1 408 801 7030| M: +1 408 780 6416 allen.samuels@xxxxxxxxxxx >>>> >>>> >>>>> -----Original Message----- >>>>> From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel- >>>>> owner@xxxxxxxxxxxxxxx] On Behalf Of Willem Jan Withagen >>>>> Sent: Thursday, December 22, 2016 9:41 AM >>>>> To: Ceph Development <ceph-devel@xxxxxxxxxxxxxxx> >>>>> Subject: An empty vptr in an raw object >>>>> >>>>>> 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<st >>>>> d::__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<st >>>>> d::_ >>>>> _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 >> > > > -- 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
