[asterisk-users] Asterisk 1.8.32.3 chan_sip deadlock

[Matthew Jordan]

On Wed, Apr 29, 2015 at 8:42 AM, Ishfaq Malik <ish at pack-net.co.uk> wrote:
> Hello asterisk-users,
>
> We've been having intermittent issues with chan_sip - it stops responding to
> cli requests, trying to reload chan_sip from cli doesn't seem to have any
> effect, initiated calls carry on for a short period, but no new SIP requests
> are processed ('sip show channels' hangs forever, server stops responding to
> SIP OPTIONS, or any other SIP messages). We have updated the build from
> 1.8.23.1 to the latest asterisk 1.8 (1.8.32.3), however the problem still
> persists. We have gathered debugging information from 'core show locks' and
> from gdb, attached to this message (with phone numbers and extension and
> context names obscured). We are running realtime under CentOS 6.6, built
> from source and packaged using rpmbuild, with the following menuselect
> options (debugging version):
> menuselect/menuselect --disable BUILD_NATIVE --enable DEBUG_THREADS --enable
> DONT_OPTIMIZE --disable CORE-SOUNDS-EN-GSM --disable-category
> MENUSELECT_EXTRA_SOUNDS --disable MOH-OPSOUND-WAV --enable-category
> MENUSELECT_ADDONS --disable format_mp3 --disable cdr_tds --disable cel_tds
> --disable cdr_pgsql --disable cel_pgsql --disable res_config_pgsql
> menuselect.makeopts
>
> under kernel 2.6.32-504.el6.x86_64, and linked against the following library
> versions:
>
> /usr/lib64/libssl.so.10:    symbolic link to `libssl.so.1.0.1e'
> /usr/lib64/libcrypto.so.10: symbolic link to `libcrypto.so.1.0.1e'
> /lib64/libc.so.6:           symbolic link to `libc-2.12.so'
> /usr/lib64/libxml2.so.2:    symbolic link to `libxml2.so.2.7.6'
> /lib64/libz.so.1:           symbolic link to `libz.so.1.2.3'
> /lib64/libm.so.6:           symbolic link to `libm-2.12.so'
> /lib64/libdl.so.2:          symbolic link to `libdl-2.12.so'
> /lib64/libpthread.so.0:     symbolic link to `libpthread-2.12.so'
> /lib64/libtinfo.so.5:       symbolic link to `libtinfo.so.5.7'
> /lib64/libresolv.so.2:      symbolic link to `libresolv-2.12.so'
> /lib64/libgssapi_krb5.so.2: symbolic link to `libgssapi_krb5.so.2.2'
> /lib64/libkrb5.so.3:        symbolic link to `libkrb5.so.3.3'
> /lib64/libcom_err.so.2:     symbolic link to `libcom_err.so.2.1'
> /lib64/libk5crypto.so.3:    symbolic link to `libk5crypto.so.3.1'
> /lib64/libkrb5support.so.0: symbolic link to `libkrb5support.so.0.1'
> /lib64/libkeyutils.so.1:    symbolic link to `libkeyutils.so.1.3'
>
>
> We'd appreciate any possible assistance, as we're having problems working
> out what exactly triggers the deadlock and we have not been able to find the
> correct sequence of steps to reproduce the issue yet, other than waiting for
> it to lock up at an arbitrary time with the debugging code in place. It does
> seem to happen at least once a day, however.
>
> What is the best way of getting the core show locks output for people to see
> as it appears to be too big to mail?
>

Please go ahead and make an issue on the issue tracker. Make sure you
get both the output of 'core show locks', as well as a GDB backtrace.
Instructions for both can be found here:

https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org