[Home]

Summary:ASTERISK-16917: Asterisk stop processing any SIP request
Reporter:Antonis Psaras (apsaras)Labels:
Date Opened:2010-11-05 03:51:50Date Closed:2010-11-11 07:13:58.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have a working installation for a year but last week I face a strange problem which cases Asterisk to stop processing any SIP request. Console and conslole commades are working fine. The box is pure VoIP (no TDM card) and has 64 SIP accounts configured with real time system. I also update the system to the latest 1.4 version without any success.

How can I take a dump from a running asterisk system in order to investigate what is causing the problem?
Comments:By: Paul Belanger (pabelanger) 2010-11-05 07:31:28

Debugging deadlocks:

Please select DEBUG_THREADS and DONT_OPTIMIZE in the Compiler Flags section of menuselect. Recompile and install Asterisk (i.e. make install)

This will then give you the console command:

core show locks

When the symptoms of the deadlock present themselves again, please provide output of the deadlock via:

# asterisk -rx \\\\\\\"core show locks\\\\\\\" | tee /tmp/core-show-locks.txt

# gdb -se \\\\\\\"asterisk\\\\\\\" <pid of asterisk> | tee /tmp/backtrace.txt

gdb> bt
gdb> bt full
gdb> thread apply all bt

Then attach the core-show-locks.txt and backtrace.txt files to this issue. Thanks!
By: Antonis Psaras (apsaras) 2010-11-11 02:29:12.000-0600

I tried the above with out the \\\\ and I get the following

for show locks

=======================================================================
=== Currently Held Locks ==============================================
=======================================================================
===
=== <file> <line num> <function> <lock name> <lock addr> (times locked)
===
=== Thread ID: 1089952064 (do_devstate_changes  started at [  363] devicestate.c ast_device_state_engine_init())
=== ---> Lock #0 (pbx.c): MUTEX 6205 ast_rdlock_contexts &conlock 0x76a8a0 (1)
=== ---> Lock #1 (pbx.c): MUTEX 2016 ast_hint_state_changed &(&hints)->lock 0x76ad70 (1)
=== ---> Waiting for Lock #2 (chan_sip.c): MUTEX 9257 cb_extensionstate &p->lock 0x1532c90 (1)
=== --- ---> Locked Here: chan_sip.c line 4964 (find_call)
=== -------------------------------------------------------------------
===
=== Thread ID: 1094416704 (do_monitor           started at [17183] chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 16852 sipsock_read &netlock 0x2aaac01415e0 (1)
=== ---> Lock #1 (chan_sip.c): MUTEX 4964 find_call &p->lock 0x1532c90 (1)
=== ---> Waiting for Lock #2 (pbx.c): MUTEX 6205 ast_rdlock_contexts &conlock 0x76a8a0 (1)
=== --- ---> Locked Here: pbx.c line 6205 (ast_rdlock_contexts)
=== -------------------------------------------------------------------
===
=== Thread ID: 1097804096 (pbx_thread           started at [ 2650] pbx.c ast_pbx_start())
=== ---> Waiting for Lock #0 (pbx.c): MUTEX 6205 ast_rdlock_contexts &conlock 0x76a8a0 (1)
=== --- ---> Locked Here: pbx.c line 6205 (ast_rdlock_contexts)
=== -------------------------------------------------------------------
===
=======================================================================

from gdb I do not get anything

GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
12925: No such file or directory.
(gdb) btNo stack.

(gdb) bt full
No stack.
(gdb) thread apply all bt
No registers.
(gdb) quit
By: Stefan Schmidt (schmidts) 2010-11-11 03:46:22.000-0600

Please have a look at the related issue 18165. There is allready a patch attached for 1.4 which solves this deadlock.
Please try this and report if its working for you.

Thanks!

Stefan
By: Paul Belanger (pabelanger) 2010-11-11 07:13:57.000-0600

Please follow up in ASTERISK-16834.