[asterisk-bugs] [Asterisk 0018132]: SIp channel stop work
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Oct 13 11:52:22 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=18132
======================================================================
Reported By: mpiazzatnetbug
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 18132
Category: General
Reproducibility: random
Severity: minor
Priority: normal
Status: new
Asterisk Version: Older 1.4 - please test a newer version
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2010-10-13 07:29 CDT
Last Modified: 2010-10-13 11:52 CDT
======================================================================
Summary: SIp channel stop work
Description:
Asterisk 1.4.26.3
It's a production enviroment.
We start asterisk in safe mode.
Every minutes with sipsak we check if sip the channel replys to a keep
alive sip message. If doesn't replay we kill the process with -6 option and
the asterisk re-starts himself.
Attached yuo find the gdp output of the core file produced by the
operation.
I'm not able to understand if the gdp outout is helpful or not. The
problem is happened after 4 weeks of uptime. We have 1020 peer registered
on the asterisk and an average of 30 channels up during office time.
I have some doubts for example about the lines as:
orig_channame =
"SIP/openser_comtn-b0bd5470\000?\000\000\000\000\020?DA\000\000\000\000%4D\000\000\000\000\000`\002\221??*\000\000\b?B\000\000\000\000\000`\002\221??*\000\000?>N\000\000\000\000"
======================================================================
----------------------------------------------------------------------
(0127956) pabelanger (manager) - 2010-10-13 11:52
https://issues.asterisk.org/view.php?id=18132#c127956
----------------------------------------------------------------------
To triage the issue, we'll need the debug information before you restart
your service. Should not be a problem automated it, be sure to check for
locks before gdb and restarting asterisk.
However, we'll need you to try and reproduce using the latest 1.4 release.
I'm remembering an issue a few month ago with MoH, looking at your
backtrace.
---
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!
Issue History
Date Modified Username Field Change
======================================================================
2010-10-13 11:52 pabelanger Note Added: 0127956
======================================================================
More information about the asterisk-bugs
mailing list