[asterisk-bugs] [JIRA] (ASTERISK-21387) Asterisk unresponsive while waiting for lock MUTEX 6239 __ast_pbx_run c

[Richard Mudgett (JIRA)]

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

Richard Mudgett edited comment on ASTERISK-21387 at 4/22/13 9:37 AM:
---------------------------------------------------------------------

I went ahead and also opened an issue for the ODBC problem I was having.

ASTERISK-21662

I tried to go back to using the ODBC connection but I see the same issue is still occurring.  Normally I would think that it might be an issue with my MySQL database but this database is a completely different database from the one I originally had the issue on.
                
      was (Author: osiris123d):
    I went ahead and also opened an issue for the ODBC problem I was having.

https://issues.asterisk.org/jira/browse/ASTERISK-21662

I tried to go back to using the ODBC connection but I see the same issue is still occurring.  Normally I would think that it might be an issue with my MySQL database but this database is a completely different database from the one I originally had the issue on.
                  
> Asterisk unresponsive while waiting for lock MUTEX 6239 __ast_pbx_run c
> -----------------------------------------------------------------------
>
>                 Key: ASTERISK-21387
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21387
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Addons/res_config_mysql
>    Affects Versions: 11.0.1, 11.2.1, 11.3.0
>         Environment: Debian 6.0.4
>            Reporter: Duane Larson
>         Attachments: backtrace-threads.txt, core-show-locks.txt, gdb debug.txt, gdb.txt
>
>
> I have tested on three different versions of Asterisk and I still have the same issue.  It appears to happen once or twice a day.  It appears to happen when a VoIP phone trys to make a call (SIP Invite).  I have two Asterisk servers that are both behind an OpenSIPS server that load balances between the two servers.  Sometimes a SIP INVITE will make only one server have a deadlock and the call can go out the second server, but most of the time both Asterisk servers will deadlock and calls cannot be made.  When I am notified that there is an issue I get on the box and execute "netstat -nap |grep 5060" add see that "Recv-Q" column value is building up.
> I've posted on the Mailing list and was told that version 11.3 fixed a lot of deadlock issues but the upgrade did not help.
> See Mailing List email here 
> http://lists.digium.com/pipermail/asterisk-users/2013-April/278436.html
> It usually takes about 10 minutes before Asterisk becomes responsive again or else before 10 minutes is up I could restart Asterisk and everything will be back to normal.
> I see in the message logs the following errors
> On the 11.0.1 Asterisk server
> WARNING[23723][C-00000010] chan_sip.c: Unable to cancel schedule ID 11473.  This is probably a bug (chan_sip.c: update_provisional_keepalive, line 4406).
> On the 11.2.1 Asterisk server
> WARNING[3493][C-0000001f] chan_sip.c: Unable to cancel schedule ID 30810.  This is probably a bug (chan_sip.c: update_provisional_keepalive, line 4683).
> When I look in chan_sip.c on both servers I see that they are the same line of code
> AST_SCHED_DEL_UNREF(sched, pvt->provisional_keepalive_sched_id, dialog_unref(pvt, "when you delete the provisional_keepalive_sched_id, you should dec the refcount for the stored dialog ptr"));
> I've seen the following debug logs
> Asterisk version 11.0.1
> [Apr  3 21:39:42] DEBUG[12984] res_timing_timerfd.c: Expected to acknowledge 1 ticks but got 11805 instead
> Asterisk version 11.2.1
> [Apr  3 21:39:50] DEBUG[1854] res_timing_timerfd.c: Expected to acknowledge 1 ticks but got 12423 instead
> Here is a gdb debug I grabbed when the issue occurred with version 11.3.0
> http://pastebin.com/gd291Bqz
> I am thinking this is a bug since it happens randomly.  Any help is appreciated.

--
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