On Sun, Sep 28, 2008 at 08:19:57PM +0930, Kevin Shanahan wrote: > Well it looked promising, but no - the lockup still appears to be > reproducable. The patch I used to test is attached. Let me know if I > made any mistake in backporting it (it should apply cleanly as the > last patch in the debian/patches/series file).
Ugh, sorry - forgot to attach the patch.
Locking fixes in chan_zap: lock chan before pvt Taken from http://repo.or.cz/w/asterisk-bristuff.git?a=commit;h=6e44531a8a112e36588b5dbced309b0521d6b64e diff -urNp a/channels/chan_zap.c b/channels/chan_zap.c --- a/channels/chan_zap.c 2008-09-28 19:33:09.000000000 +0930 +++ b/channels/chan_zap.c 2008-09-28 19:37:27.000000000 +0930 @@ -8851,7 +8851,7 @@ static void *pri_dchannel(void *vpri) int haveidles; int activeidles; int nextidle = -1; - struct ast_channel *c; + struct ast_channel *c = NULL; struct timeval tv, lowest, *next; struct timeval lastidle = { 0, 0 }; int doidling=0; @@ -9539,6 +9539,7 @@ static void *pri_dchannel(void *vpri) if (e->ring.redirectingreason >= 0) pbx_builtin_setvar_helper(c, "PRIREDIRECTREASON", redirectingreason2str(e->ring.redirectingreason)); + ast_muted_lock(&c->lock); ast_mutex_lock(&pri->pvts[chanpos]->lock); ast_mutex_lock(&pri->lock); @@ -9637,6 +9638,8 @@ static void *pri_dchannel(void *vpri) if (crv) ast_mutex_unlock(&crv->lock); ast_mutex_unlock(&pri->pvts[chanpos]->lock); + if (c) + ast_mutex_unlock(&c->lock); } else { if (e->ring.flexible) pri_hangup(pri->pri, e->ring.call, PRI_CAUSE_NORMAL_CIRCUIT_CONGESTION, -1);
