| Summary: | ASTERISK-19318: Asterisk locks up during Page cmd | ||
| Reporter: | Michael Gaudette (bluefox) | Labels: | |
| Date Opened: | 2012-02-08 18:28:20.000-0600 | Date Closed: | 2012-03-20 12:00:48 |
| Priority: | Critical | Regression? | |
| Status: | Closed/Complete | Components: | Applications/app_page |
| Versions: | 1.8.9.1 | Frequency of Occurrence | Occasional |
| Related Issues: | |||
| Environment: | Centos 5.7, Transcoder card, no PRI card on this PBX, | Attachments: | |
| Description: | Asterisk locks up (no calls dropped, but SIP stops responding) every few days. Every single time, it seems to be during a Page cmd (paging about 5 Polycom phones). There are many, many pages every day so the proportion of locked pages vs successful pages is small, but the system locking up every few days is not pleasant. Happened a few times on 1.8.8, now apparently 1.8.9.1 has the same. I can`t find a similar bug anywhere, but if there is one just please point me to it. And being pointed to a *current* how-to for debug locks would be appreciated, I will turn on what is necessary to get this issue fixed. | ||
| Comments: | By: Richard Mudgett (rmudgett) 2012-02-08 21:23:04.535-0600 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: Michael Gaudette (bluefox) 2012-02-10 05:44:46.253-0600 I compiled Asterisk with the required flags checked. My Asterisk became unresponsive, I am assuming because too much load for it to be running debug code. Do you have a good idea for a next step or a "compromise" step that won't make Asterisk unresponsive but could pinpoint the problem? By: Matt Jordan (mjordan) 2012-02-10 08:33:01.251-0600 In order to get the required information to resolve a deadlock issue, DEBUG_THREADS and DONT_OPTIMIZE are required. You should be able to execute a remote command and attach gdb to get the thread backtrace even if Asterisk becomes heavily loaded. You could attempt to reproduce the issue in a test environment with less loading. If you're unable to produce a 'core show locks' output and a thread backtrace, then there really isn't anything anyone can do to debug this issue. By: Matt Jordan (mjordan) 2012-03-20 12:00:42.460-0500 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information can be found at http://www.asterisk.org/developers/bug-guidelines | ||