[Home]

Summary:ASTERISK-14091: Core Dump on 1.4.24 - local_pvt_destroy (pvt=0x193cbc00) at chan_local.c:159
Reporter:Geoff Mina (geoff2010)Labels:
Date Opened:2009-05-07 22:16:04Date Closed:2011-06-07 14:00:30
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_local
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bt_full.txt
( 1) bt.txt
( 2) extensions.conf
( 3) thread_apply_all_bt.txt
Description:I had a server core dump on me tonight.  I have been running 1.4.21.2 without issue for a long time.  I upgraded to 1.4.24 about a month ago and just had the problem for the first time.  The server had less than 100 calls up when the problem occurred.  Based on the fact that we do a few hundred thousand calls/day and this is the first time this happened in a month, I am pretty sure I won't be able to reproduce this on-demand.

Please let me know if there is anything else I can provide.  I have attached 3 different bt outputs as well as the relevant dial plan as referenced in the back trace.

The dial plan is executed by using a manager Originate to a Local channel which then passes control off to a SIP channel.

Thanks!
Comments:By: Geoff Mina (geoff2010) 2009-05-07 22:28:00

just looking at some code here.   could this occur if for some reason pvt is null when it's passed to free()?  I would think ast_mutex_destroy would fail if pvt was NULL, but what do I know :)  I write Java, this manual memory management is for the birds!


/*!
* \note Assumes the pvt is no longer in the pvts list
*/
static struct local_pvt *local_pvt_destroy(struct local_pvt *pvt)
{
       ast_mutex_destroy(&pvt->lock);
       free(pvt);
       return NULL;
}
By: Geoff Mina (geoff2010) 2009-05-08 07:31:46

I just saw this issue for the 1.6 branch. It sounds like exactly the same thing.

http://bugs.digium.com/view.php?id=14945&nbn=5

There are no details about what changes may have been made to the chan_local hangup handling in the bug, so I can't say whether or not this is the same problem.

thanks.
By: Joshua C. Colp (jcolp) 2009-05-12 08:49:08

This has already been fixed by revision 190286 and will be in the next release. It was possible for a race condition to occur where the memory would get double freed.
By: Geoff Mina (geoff2010) 2009-05-12 09:32:06

@file, thanks for the update.  I am sorry to abuse the bug tracking system to make a note like this.. but since you closed issue 15058 I can't ask you :)

What release of asterisk is the targeted fix in?  Is it 1.4.25 or 1.4.26?  

thanks!
Geoff
By: Joshua C. Colp (jcolp) 2009-05-12 09:37:38

Since the current release is 1.4.24.1 it will be in 1.4.25.