|Summary:||ASTERISK-18080: DUNDi lookups cause deadlocks|
|Date Opened:||2011-07-01 06:57:49||Date Closed:||2011-07-20 08:26:44|
|Environment:||Attachments:||( 0) locks.txt|
|Description:||DUNDi lookups, done via switch statements on extensions.conf causes Asterisk to deadlock.|
Scenario is as follows:
1) A calls Z, an extension non-existant on its context or any other included contexts;
2) As there's a switch statement, a DUNDi lookup is done successfully and Z starts to ring;
3) From now on Asterisk is deadlocked. No new calls are possible, but the current ones continues normally.
I'm doing my tests with 18.104.22.168. The reason for that is a regression I found on 22.214.171.124 and up, which doesn't allow DAHDI FXS channels to perform transfers using hookflash and therefore I can't use anything above 126.96.36.199 in production. However, I tried using 188.8.131.52 and the same deadlock issues with DUNDi happens.
I compiled Asterisk with DEBUG_THREADS and DONT_OPTIMIZE and attached the output of core show locks when this issue arises.
|Comments:||By: viniciusfontes (viniciusfontes) 2011-07-01 06:58:15.421-0500|
Output of core show locks.
By: Leif Madsen (lmadsen) 2011-07-11 13:51:34.275-0500
Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
Are you able to reproduce this on Asterisk 1.8?
By: Leif Madsen (lmadsen) 2011-07-20 08:26:22.680-0500
Additionally, utilizing the DUNDI_LOOKUP() or DUNDI_QUERY() and DUNDI_RESULT() functions may not cause this issue which are the preferred ways of accessing DUNDi information on a network.