On Tue, Jul 26, 2016 at 10:40 PM, Allen Samuels <Allen.Samuels@xxxxxxxxxxx> wrote: >> -----Original Message----- >> From: Patrick Donnelly [mailto:pdonnell@xxxxxxxxxx] >> Sent: Tuesday, July 26, 2016 7:34 PM >> To: Brad Hubbard <bhubbard@xxxxxxxxxx> >> Cc: Allen Samuels <Allen.Samuels@xxxxxxxxxxx>; Jesse Williamson >> <jwilliamson@xxxxxxx>; kefu chai <tchaikov@xxxxxxxxx>; John Spray >> <jspray@xxxxxxxxxx>; ceph-devel@xxxxxxxxxxxxxxx >> Subject: Re: static member variable in libcommon and double free >> >> On Tue, Jul 26, 2016 at 9:54 PM, Brad Hubbard <bhubbard@xxxxxxxxxx> >> wrote: >> >> I'm guessing that the source of the problem is that the AsyncMessager.cc >> file is included twice, one in each library. If so, then the solution is to break >> out the offending *.cc file into a separate third library that's linked in the right >> combination with the others so that there's no duplication. >> >> >> > >> > I believe the problem can also be solved with a static member function >> > or a wrapper function for the static variable. I tried this and it >> > appears to resolve the issue. >> >> Another solution is to use anonymous namespaces which will force the >> symbol to be local to the translation unit. > > Won't this result in two instantiations of the "global" variable? That seems like a huge risk to the integrity of the operation of that class.... IMO, that's the wrong solution as it will eliminate a clear signal of a problem but would allow the language semantics to be degraded silently. To clarify the context, the class is defined in a .cc file so it is intended for the entire class to be local linkage. So there should not be two instantiations of a global variable. An anonymous namespace forces the entire class to have local linkage so all of its static members are not exported into global scope. (This an example of C++ abusing the well-defined C static keyword.) > I think the solution is still to properly implement the ODR rule, break this class into a separate library that's only included once in ANY build. Unless there is a convincing reason for src/common/* to be shared by librados/libceph, then I disagree. It is simpler to ensure that these modules have local linkage by explicitly managing visibility in the shared objects. -- Patrick Donnelly -- 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
