| Summary: | ASTERISK-05640: Deadlock on 'show translation' | ||
| Reporter: | damin (damin) | Labels: | |
| Date Opened: | 2005-11-18 15:49:57.000-0600 | Date Closed: | 2011-06-07 14:00:23 |
| Priority: | Critical | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | On a fresh install of CVS, on known good hardware, we can reliably get Asterisk to segfault by simply issuing a "show translation". This turns into a deadlock situation, whereby Asterisk continues to run consuming 99.9% CPU and the console simply locks up when you use "show translation recalc 5". Occasionally, Asterisk will simply segfault. Attempting to recompile using "make dont-optimize" reduces the likelyhood of a segfault, and I've not been able to get a core dump using "dont-optimize" yet. As a side note, ILBC timings on the translation table look WAY WAY out of wack. Everything else is sitting sub 10ms, while ILBC is at 6000ms. ****** STEPS TO REPRODUCE ****** 1. Download Asterisk 1.2 from cvs 2. make install 3. asterisk -rvc 4. show translation recalc 5 5. ps -aux shows 23493 root 25 0 15924 6324 3804 R 99.9 1.2 0:59.38 asterisk ****** ADDITIONAL INFORMATION ****** This is hardware that has been in production for months and is known stable when running the 1.0 CVS tree. It has passed 96 hours of memtestx86 testing. It has been pulled out of our cluster and is available for remote developer access over this weekend if neccessary. On Monday, 11-21, it must be put back into production w/ our functional 1.0 release. | ||
| Comments: | By: Donny Kavanagh (donnyk) 2005-11-18 23:48:54.000-0600 Damin as i said on irc i am unable to recreate this problem. I updated * to latest cvs and make;make installed and restarted and my show translations is fine. Is this machine running zaptel hardware? or using ztdummy? I didnt update libpri/zaptel to latest cvs, could they be comming into play somehow? i can update those later and try again. By: damin (damin) 2005-11-19 00:26:33.000-0600 To answer your questions: 1. This has a single wcfxo in it for timing purposes 2. I don't think libpri / zaptel make a difference here I've tried completely removing /usr/lib/asterisk/modules and recompiling everything. I'm not getting anywhere, but at least Asterisk isn't faulting when compiled w/ "dont-optimize". By: James Lyons (james) 2005-11-28 13:07:18.000-0600 Could not duplicate with v1-2-0 as of Nov 29 on debian 2.6.12 with no hardware. By: damin (damin) 2005-11-29 15:55:56.000-0600 I was able to pull this box out of the cluster today and play with it. I performed a fresh install of Centos 3.0 on it, updated from the 1.2 subversion archives and am now seeing more reasonable ILBC times. I can also do "show translation recalc 60" on the box without deadlocking asterisk. I'm not sure what to chalk this up to, perhaps some sort of a software glitch on the Centos 4.0 installation, but I'm going to close this bug out as I can't reproduce this again. I'll be doing some installations w/ Centos 4 using a similar hardware platform in January, so I will re-test at that time. By: damin (damin) 2005-11-29 15:57:21.000-0600 Not able to reproduce. | ||