Summary:	ASTERISK-09818: Asterisk Random Segfault (might coincide with parking a call)
Reporter:	furiousgeorge (furiousgeorge)	Labels:
Date Opened:	2007-07-06 00:52:21	Date Closed:	2007-08-21 14:35:03
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Addons/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk_messages.log ( 1) core.12739_bt.txt ( 2) core.13588_bt.txt ( 3) extensions.conf ( 4) sip.conf
Description:	Asterisk crashed earlier today and dumped a core.  Examining the backtrace reveals it was a segfault.  That is about as much as I understand. ****** ADDITIONAL INFORMATION ****** This server has never worked right.  The difference between this one and all the other ones I've installed is that we use device states on parking extensions. These backtraces are from 1.4.5, but I've since upgraded to 1.4.6.  As per Russell's request I filed a bug report anyway.
Comments:	By: furiousgeorge (furiousgeorge) 2007-07-17 11:18:40 UPDATE: I had an unrelated hardware issue that forced me to restart the server a few days after upgrading, but I'm happy to report since then I have 7 days of uptime (which lately is something of an accomplishment at this location). Unfortunately, I have no way of knowing if it was the upgrade to 1.4.6 or the abandoning of our phone's ParkOrbit feature which has at least to some extent helped our stability.  I'm strongly leaning toward the latter, as I have other identical servers that never experience this issue, and never or rarely use ParkOrbit. If I'm correct about that last part then I assume the issue SHOULD be resolved, but only time will tell. By: furiousgeorge (furiousgeorge) 2007-07-23 13:26:46 Time has told. The server crashed today just short of 14 days of uptime. It didn't dump a core, but I do see this in the log: [Jul 23 13:13:37] NOTICE[20186] chan_zap.c: Got event 18 (Ring Begin)... [Jul 23 13:13:53] WARNING[20219] res_features.c: Whoa, failed to remove the extension! [Jul 23 13:13:54] ERROR[20215] /usr/src/asterisk-1.4.6/include/asterisk/lock.h: channel.c line 4849 (ast_channel_lock): Error obtaining mutex: No such file or directory There was one person using the system at the time and according to him, he had placed a call out over IAX when another call came in.  He attempted to end the first call and answer the second, but the server must have crashed before he was able to do so. This is the first ever occurance of the word "Whoa" in my messages log, for whatever that is worth. What should I do now? By: Mark Michelson (mmichelson) 2007-07-24 16:28:18 Unfortunately, this won't be possible to debug without a backtrace, and more than likely, a thread apply all backtrace. Asterisk should dump a core for any crash that happens. Make sure you're running with the -g option and that your ulimit -c is unlimited. I don't like that "Whoa" message, and unfortunately there are three places in res_features.c where that EXACT same message appears, which is what makes debugging this without a backtrace nearly impossible. Edit: I assumed from your remark about this being the first time a "Whoa" message had appeared in your log that this crash was different from your first one you reported. This is why I'm assuming I'll need a new backtrace. By the way, Corydon76 pointed something out to me from the backtrace you included in the initial report. You appear to be trying to park yourself. When you do this, does Asterisk consistently crash? By: furiousgeorge (furiousgeorge) 2007-08-21 14:23:31 I apoligize for the extended delay in responding. This issue appears to be resolved.  I met with the users and advised there would need to be a change in how we park calls.  Then I simply disabled the Snom 3XX's Park Orbit feature, forcing the users to transfer to the "Park" function button, rather than simply hitting "Park" and parking the call. Since then, asterisk has not deadlocked or crashed. putnopvut, I was not trying to park myself.  It may be that the Park Orbit feature is not executing a simple  blindXfer-to-park-extension on the active call, as I thought it was, and instead was doing something else that resulted in the functional equivalent of the call being parked. iirc, i was calling in on my cell and parking myself. I wish I were fluent in SIP, then perhaps I could assist in making sense of the sip debug. By: Mark Michelson (mmichelson) 2007-08-21 14:35:03 Since the problem is no longer happening, I'm closing this.