From e08cb0ffa6dbd44c975ad5186f326ba2ee94b718 Mon Sep 17 00:00:00 2001 From: tilghman Date: Fri, 2 Jul 2010 21:36:39 +0000 Subject: Have the DEADLOCK_AVOIDANCE macro warn when an unlock fails, to help catch potentially large software bugs. (closes issue #17407) Reported by: pdf Patches: 20100527__issue17407.diff.txt uploaded by tilghman (license 14) Review: https://reviewboard.asterisk.org/r/751/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@273793 f38db490-d61c-443f-a65b-d21fe96a405b --- channels/chan_dahdi.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'channels/chan_dahdi.c') diff --git a/channels/chan_dahdi.c b/channels/chan_dahdi.c index e9cf2db4d..e47b56107 100644 --- a/channels/chan_dahdi.c +++ b/channels/chan_dahdi.c @@ -4399,8 +4399,12 @@ static struct ast_frame *dahdi_handle_event(struct ast_channel *ast) /* Here we have to retain the lock on both the main channel, the 3-way channel, and the private structure -- not especially easy or clean */ while (p->subs[SUB_THREEWAY].owner && ast_mutex_trylock(&p->subs[SUB_THREEWAY].owner->lock)) { + int res; /* Yuck, didn't get the lock on the 3-way, gotta release everything and re-grab! */ - ast_mutex_unlock(&p->lock); + if ((res = ast_mutex_unlock(&p->lock))) { + ast_log(LOG_ERROR, "chan_dahdi bug! '&p->lock' was not locked upon entry to 'dahdi_handle_dtmfup': %s\n", strerror(res)); + return NULL; + } DEADLOCK_AVOIDANCE(&ast->lock); /* We can grab ast and p in that order, without worry. We should make sure nothing seriously bad has happened though like some sort of bizarre double -- cgit v1.2.3