Hi, Thanks for looking at this.
On 29 January 2014 16:34, Matthew Jordan <[email protected]> wrote: [snip] > You'll note that the refcall is only called if ast_sched_del > (eventually) returns a valid ID that it deleted. Agreed. In my proposed "failure" example, ast_sched_del is called first, and is called in many places in chan_sip with an unref function provided. As a result, ast_sched_del will indeed decrease the refcount. The ASTERISK-22079 backtrace refers to a keepalive timer that will be cancelled more often than it is needed in most environments, so this cancel code should execute regularly. In general, chan_sip > doesn't let the scheduler re-schedule events itself, which means that > if the scheduler fires the event, then only the event callback should > un-ref the object (thus consuming the reference of the ao2 object when > it was put on the scheduler). If the scheduler doesn't fire the event > and the delete call wins the lock contention, then the delete call > should unref the object, and the event should never fire. > If the scheduler wins, it does not know whether to delete the scheduled job from the queue until execution ends because the re-scheduling is determined by the return value from the event-call. If the event call is blocked waiting for a lock, then there could be plenty of time for ast_sched_del to get called from elsewhere between the start and end of the event execution. The specific example in ASTERISK-22079 might be fixed by checking whether the pvt->keepaliveschedid (variable name is from memory) has changed either side of grabbing the pvt and chan locks in the event. If it has changed, bail. If that change is right, it should also allow for the big "#if 0 ..TODO" block in the keepalive code to be reactivated. Perhaps I'll try that and put some highly verbose logging in there to indicate what is happening in real life? Thanks again, Steve
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
