Could try '-Og -g' as well On Fri, Dec 23, 2016 at 10:53 AM, Willem Jan Withagen <wjw@xxxxxxxxxxx> wrote: > On 23-12-2016 01:49, Allen Samuels wrote: >> Usage of vptr shouldn't be very different between them. > > Note that I also compile '-O0 -g' to get the most unbiased debugging, > and the GCC in the jenkins.ceph.com builders runs wiht optimizing on. > > So that would/could be a difference. > > --WjW > >> >> >> 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 4:48 PM >>> To: Brad Hubbard <bhubbard@xxxxxxxxxx>; Allen Samuels >>> <Allen.Samuels@xxxxxxxxxxx> >>> Cc: Ceph Development <ceph-devel@xxxxxxxxxxxxxxx> >>> Subject: Re: An empty vptr in an raw object >>> >>> 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 >>>>> >>>> >>>> >>>> >> > -- Cheers, Brad -- 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
