On 10/16/2010 01:44 AM, Toralf Wittner wrote: > Attached is the signed off patch. > Thanks! Applied to the master. >> However, while the above is definitely a bug, I don't think it can actually >> cause the pure virtual method to be called. Or am I missing something. >> > This is related to the way instances of derived classes are > constructed/destroyed which is a multi-step process. First the base > class constructor is called and this refers to the virtual method > table (vtbl) of base class. Then - before the derived constructor is > called - this is reset to the vtbl of the derived class. When an > instance is deleted the process is reversed, so after the derived > destructor finishes, this refers to the base class vtbl and the base > class destructor is invoked. > > Now what we have here is that in poller_base_t::execute_timers() we > use a (dangling) pointer to a base class i_poll_events after the > instance has been deleted. Technically this results in undefined > behaviour but if the memory is still available, then the object the > pointer points to will refer only to the base class vtbl because the > destructor chain finished like described above which thus causes the > pure virtual method error when we call > i_poll_events::timer_event(int). But - this being undefined behaviour > - it could as well result in a segmentation fault instead. > The above is clear. What I meant was: Can you think of a sequence of steps that would lead to base class keeping a dangling pointer? When pgm_sender is unplugged, all such pointers should be dropped, no?
Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
