Summary:	ASTERISK-16966: [patch] Asterisk segfaults on /lib/i686/cmov/libc.so.6
Reporter:	viniciusfontes (viniciusfontes)	Labels:
Date Opened:	2010-11-16 06:29:31.000-0600	Date Closed:	2011-07-27 13:06:11
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) backtrace.txt ( 1) fullbt-thread.txt ( 2) issue18315.patch
Description:	Running on Debian Lenny 5.0.1, 32-bit. Crashes occur at random, several times a day. Compiled with DONT_OPTIMIZE and DEBUG_THREADS. Backtrace attached. Here's a snippet of /var/log/asterisk/messages when the crash occurs: [2010-11-16 09:55:07] VERBOSE[25362] netsock.c: [2010-11-16 09:55:07]   == Using SIP RTP TOS bits 184 [2010-11-16 09:55:07] VERBOSE[25362] netsock.c: [2010-11-16 09:55:07]   == Using SIP RTP CoS mark 5 [2010-11-16 09:55:07] VERBOSE[25362] netsock.c: [2010-11-16 09:55:07]   == Using SIP VRTP TOS bits 96 [2010-11-16 09:55:07] VERBOSE[25362] netsock.c: [2010-11-16 09:55:07]   == Using SIP VRTP CoS mark 6 [2010-11-16 09:55:07] VERBOSE[30272] pbx.c: [2010-11-16 09:55:07]     -- Executing [3125@interno:1] Macro("SIP/3122-00000119", "ramalsip-vm,interna,3125") in new stack [2010-11-16 09:55:07] VERBOSE[30272] pbx.c: [2010-11-16 09:55:07]     -- Executing [s@macro-ramalsip-vm:1] GotoIf("SIP/3122-00000119", "0?sigame:interna") in new stack [2010-11-16 09:55:07] VERBOSE[30272] pbx.c: [2010-11-16 09:55:07]     -- Goto (macro-ramalsip-vm,s,4) [2010-11-16 09:55:07] VERBOSE[30272] pbx.c: [2010-11-16 09:55:07]     -- Executing [s@macro-ramalsip-vm:4] Dial("SIP/3122-00000119", "SIP/3125,30,tTrL(14400000)") in new stack [2010-11-16 09:55:07] VERBOSE[30272] app_dial.c: [2010-11-16 09:55:07]     -- Setting call duration limit to 14400.000 seconds. [2010-11-16 09:55:07] VERBOSE[30272] netsock.c: [2010-11-16 09:55:07]   == Using SIP RTP TOS bits 184 [2010-11-16 09:55:07] VERBOSE[30272] netsock.c: [2010-11-16 09:55:07]   == Using SIP RTP CoS mark 5 [2010-11-16 09:55:07] VERBOSE[30272] netsock.c: [2010-11-16 09:55:07]   == Using SIP VRTP TOS bits 96 [2010-11-16 09:55:07] VERBOSE[30272] netsock.c: [2010-11-16 09:55:07]   == Using SIP VRTP CoS mark 6 [2010-11-16 09:55:07] VERBOSE[30272] app_dial.c: [2010-11-16 09:55:07]     -- Called 3125 [2010-11-16 09:55:07] VERBOSE[30272] app_dial.c: [2010-11-16 09:55:07]     -- SIP/3125-0000011a is ringing [2010-11-16 09:55:10] VERBOSE[30272] app_dial.c: [2010-11-16 09:55:10]     -- SIP/3125-0000011a answered SIP/3122-00000119 [2010-11-16 09:55:11] VERBOSE[25362] res_musiconhold.c: [2010-11-16 09:55:11]     -- Stopped music on hold on DAHDI/33-1 [2010-11-16 09:55:11] VERBOSE[30170] app_macro.c: [2010-11-16 09:55:11]   == Spawn extension (macro-ramalsip-vm, s, 4) exited non-zero on 'DAHDI/33-1<MASQ>' in macro 'ramalsip-vm' [2010-11-16 09:55:11] VERBOSE[30170] pbx.c: [2010-11-16 09:55:11]   == Spawn extension (interno, 3100, 1) exited non-zero on 'DAHDI/33-1<MASQ>' And this shows up on syslog: Nov 16 09:55:11 migplus kernel: [2496666.253535] asterisk[30223]: segfault at 36 ip b7d2ec1a sp b6397e8c error 6 in libc-2.7.so[b7cb7000+155000]
Comments:	By: Stefan Schmidt (schmidts) 2010-11-16 07:14:05.000-0600 the output of bt full and thread apply all bt from gdb could be usefull here too so please add this if possible. just an idea i have, do you use a DB backend for cdrs like cdr_mysql? If yes is it possible that this mysql backend was unreachable when this happens? as i said this is just an idea what could cause this. By: viniciusfontes (viniciusfontes) 2010-11-16 07:17:01.000-0600 Unfortunely I don't have the core dump file anymore, so I'll have to wait the next segfault to occur in order to get a full bt. Yes, I do have cdr_addon_mysql running.  MySQL runs on the same machine so it's never unreachable. By: Stefan Schmidt (schmidts) 2010-11-16 07:24:30.000-0600 never say never :D pleasy try the attached patch, i am not sure if this helps but if you hit the same problem i had it could help. By: viniciusfontes (viniciusfontes) 2010-11-16 07:29:04.000-0600 The patch failed to apply: migplus:/usr/src/asterisk-1.6.2.14# patch -p1 < 1.patch missing header for unified diff at line 3 of patch patching file main/features.c Reversed (or previously applied) patch detected!  Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 2972. 1 out of 1 hunk FAILED -- saving rejects to file main/features.c.rej By: Stefan Schmidt (schmidts) 2010-11-16 07:47:35.000-0600 sorry maybe you can change it by yourself its just the order of checks in this if. By: viniciusfontes (viniciusfontes) 2010-11-16 07:51:41.000-0600 Just checked. This patch is for 1.6.2.14-rc1, I'm running 1.6.2.14 and it's already patched. By: Andre Luis (andrel) 2010-11-16 07:59:01.000-0600 Seems a lot like my crashes but only happens when i use DUNDi, during normal use at the day it doesn't crash at all. my issues are = 0017993 0018208 0017984 By: viniciusfontes (viniciusfontes) 2010-11-16 08:03:01.000-0600 I'm not using DUNDi on this machine. By: viniciusfontes (viniciusfontes) 2010-11-17 09:42:41.000-0600 As requested, I added the gdb output of "bt full" and "thread apply all bt". By: wushumasters (wushumasters) 2010-11-23 16:38:33.000-0600 I have the same problem sometimes. kernel: [1642734.471309] asterisk[4206]: segfault at 44 ip b76c1caf sp b01f4760 error 6 in libc-2.7.so[b764f000+138000] By: Leif Madsen (lmadsen) 2010-12-06 13:28:08.000-0600 FYI: 1.6.2.14-rc1 and 1.6.2.14 would be exactly the same, so it doesn't matter the patch schmidts supplied was created against 1.6.2.14-rc1. By: viniciusfontes (viniciusfontes) 2010-12-17 06:20:01.000-0600 Tested the patch, didn't solve the problem. By: Andre Luis (andrel) 2011-06-15 09:04:34.293-0500 The problem is gone on newer versions! By: Russell Bryant (russell) 2011-07-27 13:05:55.195-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!