Summary:	ASTERISK-13856: Asterisk abort (signal 6) in local_pvt_destroy at chan_local.c:159
Reporter:	Jens von Bülow (jensvb)	Labels:
Date Opened:	2009-03-30 01:26:44	Date Closed:	2011-06-07 14:00:50
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_local
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) backtrace.txt
Description:	ASTERISK-1  0x00002aaab4ff8d08 in local_pvt_destroy (pvt=0x2aaadc45eff0) at chan_local.c:159        __PRETTY_FUNCTION__ = "local_pvt_destroy"
Comments:	By: Jens von Bülow (jensvb) 2009-03-30 01:29:39 attached backtrace to issue - "bt full" in backtrace.txt By: Joshua C. Colp (jcolp) 2009-03-31 09:41:02 It doesn't actually look like you attached it. I would also suggest you use the latest version, there have been fixes in this specific area. By: Jens von Bülow (jensvb) 2009-04-01 02:14:56 1) backtrace uploaded and confirmed there.... sorry about that. 2) I am hesitant to upgrade to 1.4.24 right away... I normally wait a while and then do quite a bit of research. My experiences with upgrades haven’t been good. 3) We have traced the problem to an incoming call to a queue (general reception queue) which is transferred to a sip extension.... when the user hangs up the call asterisk crashes By: Leif Madsen (lmadsen) 2009-04-01 09:28:08 Are you able to test this on a development system (which you should be doing whenever you perform an update -- you shouldn't update production servers without prior testing)? If file feels some work has already been done here to solve this, I'm going to be tempted to close this until you are able to reproduce on a later version in order to avoid this issue going stale. By: Jens von Bülow (jensvb) 2009-04-01 09:38:41 >> Are you able to test this on a development system >> (which you should be doing whenever you perform an >> update -- you shouldn't update production servers >> without prior testing)? Since this is public forum I would like to make the point that we do test before rolling out. It is my opinion that almost everything works in test. The real problems pop up when you stress test things in the real world. For the record, we have testing box which we use to test new releases. Once we feel ok, we move the release to our general office asterisk server. After about a month, we move the new release to our 100 seat call centre.  If all goes well..... About 4 times a year (generally) we move that release to our client call centres.... If all goes well.... >> If file feels some work has already been done here >> to solve this, I'm going to be tempted to close this >> until you are able to reproduce on a later version >> in order to avoid this issue going stale. Ok. I will schedule moving 1.4.24 to our general office asterisk server this Thursday evening. By: Joshua C. Colp (jcolp) 2009-04-01 09:44:06 If it still doesn't work the exact call scenario and console output would also be useful. By: Tilghman Lesher (tilghman) 2009-04-01 12:57:28 Also, if signal 6 (abort) is what you continue to see, then the debugging method of choice is valgrind (see doc/valgrind.txt). By: Leif Madsen (lmadsen) 2009-04-13 13:32:08 Pinging reporter :)  Would be ideal if we can move this issue forward. Policy is to close issues without information after about 7-10 days. Thanks! By: Jens von Bülow (jensvb) 2009-04-14 04:59:08 Hi. I have not been able to reproduce this bug again. We also found that the crash we specific to 1 Queue and 1 specific Agent. After investigation, we found that the receptionist was running a Snom 360 (all others a snom 320) with older firmware. We have replaced the Snom 360 with a 320 (as per our standard) and Asterisk has not crashed again. If this bug pops up again I will open the bug again. By: Leif Madsen (lmadsen) 2009-04-15 11:17:26 Closing per the reporter. Thanks for following up!