VoIP Mailing List Archives

[ish at pack-net.co.uk]

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?


Ish


--

[mjordan at digium.com]

On Wed, Apr 29, 2015 at 8:42 AM, Ishfaq Malik <ish@pack-net.co.uk> wrote:

[jcolp at digium.com]

Ishfaq Malik wrote: