Summary:	ASTERISK-20515: core dump in ast_channel_destructor if chan->tech_pvt is not null
Reporter:	Bob Stine (rstinejr)	Labels:
Date Opened:	2012-10-04 12:13:16	Date Closed:	2012-10-04 15:05:05
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/General
Versions:		Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) backtrace.txt
Description:	CentOS 6.2, 32-bit, running as VM in VMware.
Comments:	By: Matt Jordan (mjordan) 2012-10-04 13:50:56.747-0500 Hold on. As this is your channel driver, it is not a bug in Asterisk.  If you need help with development activities, the proper forum is the asterisk-dev mailing list. As far as {{ast_channel_destructor}} goes, every channel driver *must* either assign its private object to tech_pvt, or set it to NULL.  In fact, if you're building out your channel properly, you should be calling ast_channel_alloc, which will use ao2_alloc to create the channel object.  The tech_pvt member *will* be set to NULL at that point.  If you're creating your channel driver via some other mechanism, or other wise mucking up the tech_pvt pointer, that's not Asterisk's fault. By: Joshua C. Colp (jcolp) 2012-10-04 13:55:04.448-0500 Going down this rabbit hole more - the code present there is a "worst case stab" approach to get rid of the tech_pvt. It is your responsibility in the hangup callback (or elsewhere, depending upon channel driver design) to set it to NULL and ensure it gets freed in the implementation specific manner. By: Matt Jordan (mjordan) 2012-10-04 14:00:38.105-0500 Please do e-mail the asterisk-dev list with these kinds of questions - there are lots of Asterisk developers out there who can help you with the semantics of the channel driver.  JIRA is not always monitored by all Asterisk developers, and doesn't provide the best forum for answering these kinds of issues. By: Bob Stine (rstinejr) 2012-10-04 14:04:45.928-0500 The custom driver is my responsibility, but for ast_channel_destructor to attempt cleanup by freeing the value is a poor choice.   An assertion that tech_pvt is null would be better. By: Bob Stine (rstinejr) 2012-10-04 14:16:50.151-0500 backtrace from gdb for core dropped by asterisk. By: Bob Stine (rstinejr) 2012-10-05 07:23:49.897-0500 The problem that I reported occurred in an error handling block.  Action taken by the block is, as far as I can tell, guaranteed to cause a core dump.  Unintentionally dropping core strikes me as a bug. Logging a strident warning, asserting that the value should be null, etc., would be better than trying to free a block of memory when that just won't work. By: Bob Stine (rstinejr) 2012-10-05 07:25:55.771-0500 Another alternative would be to close this with "won't fix", since it's not worth the QA and development time, although I think that doing nothing (logging the problem or just letting it go) is better than doing something wrong.