| Summary: | ASTERISK-18491: Deadlock on chan_sip / MASTER_CHANNEL | ||
| Reporter: | Stefan Lekov (arcopix) | Labels: | |
| Date Opened: | 2011-09-09 04:26:58 | Date Closed: | 2011-09-14 12:57:21 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | General |
| Versions: | 1.8.5.0 1.8.6.0 | Frequency of Occurrence | Occasional |
| Related Issues: | |||
| Environment: | Debian Squeeze (2.6.32-5-amd64), 64 bit system, 8 core @ Intel(R) Xeon(R) CPU X3440 @ 2.53GHz, 8GB RAM, Dual Intel Corporation 82574L ethernet interfaces, no specialized telephony hardware installed | Attachments: | ( 0) backtrace-threads.txt ( 1) locks.txt ( 2) threads-info.txt |
| Description: | Asterisk is compiled from source, usage of AGI scripts, realtime configuration for SIP (mySQL) and voicemail. Dialplan is relatively short (about 12kB total) and the average load is about 0.1~0.2. Average concurrent channels: 2.7 At random intervals (it happened about 6 times the last 10 days, 3 of those occasions were last two days) Asterisk deadlocks. It doesn't accept new calls, and is not responding to SIP packets. Usage of <core show channels> is hanging the CLI. I've checked <core show locks> and I will be attaching this information. We have done backtraces of all threads (info to follow). We have seen the issue on 1.8.5.0 and have upgraded to 1.8.6.0, issues is still occurring. All debug informations is from (1.8.6.0). | ||
| Comments: | By: Stefan Lekov (arcopix) 2011-09-09 04:28:37.602-0500 This is output of <core show locks> By: Stefan Lekov (arcopix) 2011-09-09 04:29:12.869-0500 Summary of the threads. By: Stefan Lekov (arcopix) 2011-09-09 04:29:34.446-0500 Backtrace of all threads. By: Gregory Hinton Nietsky (irroot) 2011-09-09 15:18:21.251-0500 This is a problem with res_timing_timerfd.so please disable it in modules.conf use dahdi or please upgrade to 1.8.7-rc1 or better. Thread 3 (Thread 0x7f7aa7086700 (LWP 53827)): #0 0x00007f7ac72e0ebd in read () from /lib/libc.so.6 #1 0x00007f7abbb502dc in timerfd_timer_ack (handle=73, quantity=1) at res_timing_timerfd.c:167 #2 0x000000000055c7a4 in ast_timer_ack (handle=0x7f7aa00279c8, quantity=1) at timing.c:169 #3 0x00000000004751fa in __ast_read (chan=0x7f7aa00f0980, dropaudio=0) at channel.c:3788 This problem is known and resolved. | ||