On Fri, Oct 30, 2009 at 5:09 PM, David Levin <le...@chromium.org> wrote: > > > On Fri, Oct 30, 2009 at 3:59 PM, Antoine Labour <pi...@google.com> wrote: >> >> >> On Fri, Oct 30, 2009 at 3:54 PM, Jeremy Orlow <jor...@chromium.org> wrote: >>> >>> On Fri, Oct 30, 2009 at 3:46 PM, Scott Hess <sh...@chromium.org> wrote: >>>> >>>> Just to be clear for those of us who are wobbly on C++, this is >>>> because during the constructor or destructor, your object is of the >>>> class in question, NOT of the class it will finally be, because in the >>>> constructor the subclass has not been constructed, yet, and in the >>>> destructor the subclass was already destructed. So calling to the >>>> subclass virtual implementation would be bad. >>>> >>>> Scott Meyers says: http://www.artima.com/cppsource/nevercall.html >>>> >>>> Is there any way we could modify an object to assert that it can't >>>> happen in development? Like scoped_vtable_killer declared in the >>>> constructor and destructor which makes calling a virtual method on >>>> that object fatal? >>> >>> Or is there any sort of built in compiler warning that we could turn on? >>> I did a bit of searching and was really surprised that I couldn't find any >>> mention of such a thing. >> >> The compiler could find if it's called directly from the destructor, but >> there's no way it'd find your case ! The virtual call happens on another >> thread. >> To Scott's question: you can blit NULL into the vtable field, if you know >> where it is (it's not too hard, but depends on the compiler). You'll know if >> you call it - you'll die. > > For the original issue this doesn't work b/c for virtual calls in the > constructor/destructor, the compiler may optimize them to be non-virtual.
Good point. Given this, I'd suggest that the "poison vtable" approach would be better implemented as a compiler feature. When the flag is enabled, the compiler would specifically avoid these optimizations. Perhaps this would only work in debug builds. Erik > Also, it looks like this keeps biting > chromium: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475 > >> >> Better yet, you could have a static table of functions that print a >> message before dying and blit that one, but that gets trickier. >> Antoine >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
