[asterisk-dev] iax2_sched_replace: Unable to cancel schedule

[Tilghman Lesher]

On Friday 02 May 2008 00:07:39 Timo Teräs wrote:
> Timo Teräs wrote:
> > I'm getting log messages such as:
> >
> > [Apr 30 11:29:48] WARNING[15015]: chan_iax2.c:1103 iax2_sched_replace:
> > Unable to cancel schedule ID 8973.  This is probably a bug (chan_iax2.c:
> > iax2_sched_replace, line 1103). [Apr 30 11:29:55] WARNING[15015]:
> > chan_iax2.c:1103 iax2_sched_replace: Unable to cancel schedule ID 9336. 
> > This is probably a bug (chan_iax2.c: iax2_sched_replace, line 1103). [Apr
> > 30 11:29:56] WARNING[15015]: chan_iax2.c:1103 iax2_sched_replace: Unable
> > to cancel schedule ID 9487.  This is probably a bug (chan_iax2.c:
> > iax2_sched_replace, line 1103).
> >
> > on Asterisk 1.6.0-beta8 (with connectedline patches).
> >
> > Any suggestions how to debug those?
>
> Ok. I think I got it. I get these on a slow machine. So I think the problem
> is the usage of AST_SCHED_REPLACE() in iax2_sched_replace(). Looking at the
> comments in sched.h ASC_SCHED_REPLACE() should be used only for entities
> where the scheduler callback returns non-zero to get injected back to
> scheduler queue with same id. It looks like to me that all scheduler
> callbacks return zero so usage of this macro is incorrect (the macro
> assumes that the ID is always valid; and if it's not then the scheduler
> callback is being run in another thread and reinjected soon; so it loops a
> couple of times trying to delete it again). Doing
> s/AST_SCHED_REPLACE/ast_sched_replace/ in chan_iax2.c cured the problem for
> me. Now I'm wondering why ast_sched_replace is marked deprecated in
> sched.h? Clearly it has valid usages where AST_SCHED_REPLACE is not
> appropriate.

That comment is in the process of being revised, because it was based on a
fundamental misunderstanding of how the code works.  There is indeed a bug
in chan_iax2 where a scheduled process either does not reset its ID upon death
or it's hanging out for WAY too long.

Setting the routine back to the function instead of the macro doesn't "fix"
anything; it merely hides the problem.

-- 
Tilghman