[asterisk-bugs] [JIRA] (ASTERISK-21431) SIP deadlock when trying to send T.38 faxes

[Tim Heath (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Heath updated ASTERISK-21431:
---------------------------------

    Attachment: digiuminfo_20110914.txt
                ami-capture0412.txt
                coreout.txt
                digium-autosupport_20110914.tar.gz

Please find attached, output of autosupport, AMI debug capture, and "coreout.txt" showing "core show locks".
                
> SIP deadlock when trying to send T.38 faxes
> -------------------------------------------
>
>                 Key: ASTERISK-21431
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21431
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>         Environment: Linux version 2.6.32.9-rscloud
> Asterisk 1.8.21.0 
> Digium FAX Driver: 1.8.4_1.3.0 (optimized for barcelona_64)
>            Reporter: Tim Heath
>         Attachments: ami-capture0412.txt, coreout.txt, digium-autosupport_20110914.tar.gz, digiuminfo_20110914.txt
>
>
> Customer has a sever that is only used to handle faxes over t.38, but that intermittently hangs when sending a fax. Latest from the customer:
> Summary:
> This morning (4/13) a fax was attempted at 7:46 which was not responded to. At that point all sip messages ended.
> Prior to 7:46 the latest successful fax was about 7:30 pm, which is not in the capture file(s) and is not interesting.
> there is no voice traffic on this system, so the only events since then have been FAX ATA's registering every 2 mins or so.
> Starting at 7:46 am, all subsequent registration events go unresponded to. chan_sip is hung.
> Details:
> We have used monit to run a script every minute. This script does a core show locks, and looks for _res_timing_thread in the lock output.
> When we see it, we generate a gdb backtrace as well.
> We do see this occasionally, and it is not indicative of the hang. It usually clears by the next monit run. However, when it does not clear, and in this case we had the monit match at 7:30, then it is always indicative of a hang. The hang might not have happened yet, but it will. This morning, the monit alert was at 7:30, and the fax we sent at 7:46 produced the results in the pcap file.
> The astlocks and gdb output are at 7:30. In retrospect, we should also get the astlocks/gdb output at the point of the hang, which in this case was 7:46. we will get that data in the next hang case, However, I think that the chan_sip hang is a secondary effect: chan_sip hung on something that is presented in the current astlocks file.

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