Any clue from Valgrind? Did you say this only happens with clang or doesn't happen with clang? 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
