On 10/16/2010 08:06 PM, Toralf Wittner wrote: > On Sat, Oct 16, 2010 at 8:34 AM, Martin Sustrik<[email protected]> wrote: > >> 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? >> > poller_base_t::cancel_timer assumes there exists exactly one timer for > a given id. But this was not the case for pgm_sender_t::tx_timer_id > before the patch was applied. Whenever pgm_sender_t::out_event could > not write its data, another timer got added but never removed. > pgm_sender_t::unplug then called poller_base_t::cancel_timer so only > one of those timers got canceled and the others remained active with > dangling i_poll_events pointers. Now with the patch in place this can > not happen anymore, at least with regards to pgm_sender_t::tx_timer_id > and pgm_sender_t::rx_timer_id. > Oh my! You are right :)
The timer API should be refactored to prevent that kind of thing... Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
