[asterisk-bugs] [JIRA] (ASTERISK-21228) Deadlock in pbx_find_extension when attempting an autoservice stop due to holding the context lock

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205879#comment-205879 ] 

Matt Jordan commented on ASTERISK-21228:
----------------------------------------

Dare:

Well, I can tell you that you're running into this due to the {{switch}} in the dialplan - that would be why you're seeing this when few others are. Everytime a switch is executed, the channel is put into {{autoservice}} - the act of taking it out of {{autoservice}} while holding the context lock is what causes this issue. That, and {{pbx_realtime}} being extended support - it does not receive a lot of developer attention.

Tilghman:

That might work, but it'd be nice if we didn't have to rely on such a measure. Unfortunately, that would probably require a wholesale move to ao2 in pbx.c, as well as a significant restructuring of the dialplan logic.
                
> Deadlock in pbx_find_extension when attempting an autoservice stop due to holding the context lock
> --------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21228
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21228
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/PBX
>    Affects Versions: 1.8.20.1, 1.8.21.0, 11.2.1, 11.3.0
>         Environment: Linux 3.2.0-38-generic #61-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Dare Awktane
>            Severity: Critical
>         Attachments: 1366481920-backtrace_threads.txt, 1366481920-core_show_locks.txt, 1366495718-backtrace_threads.txt, 1366495718-core_show_locks.txt, 20130425__AST-21228.patch, backtrace-threads.txt, core-show-locks.txt
>
>
> We have two asterisk machines running inbound/outbound/fax calls on both. We've developed a web application that people can use to create accounts (which flow through into asterisk as contexts). We have a cron script that calls -rx "dialplan reload" to update these contexts. Both the extconfig.conf and extensions.conf are loaded from a mysql clustered (ndb) database. Roughly 2-3 times a day each asterisk server stops taking calls and does not restart on its own. I'm not sure if all of the lockups are related to this dump. We braved a morning of bad call quality to have the debug flags set. Our dialplan shows that it has 494197 rows. A reasonably large dialplan.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira