Summary:	ASTERISK-10974: [patch] h extension not executing, zap channel getting stuck
Reporter:	jmls (jmls)	Labels:
Date Opened:	2007-12-04 15:51:58.000-0600	Date Closed:	2007-12-07 09:38:09.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/Channels
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 11467.patch
Description:	If either func_curl or func_odbc is executed, and during the time it takes to execute the function the caller hangs up, then the h extension is not executed, and the zap channel the call came in on gets "stuck"
Comments:	By: Tilghman Lesher (tilghman) 2007-12-05 17:25:19.000-0600 Need a gdb attached "thread apply all bt" and a "core show locks". By: Mark Michelson (mmichelson) 2007-12-06 18:53:56.000-0600 I was able to reproduce this problem using the "memberdelay" option for queues. The problem is with hanging up while a channel is being autoserviced. The problem stems from the fact that a hangup actually generates a NULL frame, not a hangup frame. I have uploaded a patch which will fix the problem, but I'm not sure if this should be merged as is. This fix simply queues the hangup frame, and the frame will not be processed until autoservice is stopped on the channel. This means that in the case reported here, the hangup will not actually occur until after the call to odbc or curl has finished. The other way to go would be to treat a hangup as a sign to immediately stop autoservice and process the hangup. Thoughts? By: Leif Madsen (lmadsen) 2007-12-06 22:26:09.000-0600 In the case of ODBC, I want the process to finish for sure if I'm doing an insert or an update. In the case of a select I probably don't care that much... but to be safe, I'd say let the process finish with something like rtptimeout where you will kill something if it doesn't return within a period of time. Is that possible? By: jmls (jmls) 2007-12-07 01:09:57.000-0600 either, or. I don't care when the h is called, as long as it is ;) By: Mark Michelson (mmichelson) 2007-12-07 09:24:06.000-0600 I talked this over with Qwell last night and we both agreed that the way I have implemented this in the patch feels safest because applications/functions do not expect the channel to be hung up during autoservice and it could cause unexpected behavior if it were. By: Digium Subversion (svnbot) 2007-12-07 09:37:09.000-0600 Repository: asterisk Revision: 91737 U   branches/1.4/main/autoservice.c ------------------------------------------------------------------------ r91737 | mmichelson | 2007-12-07 09:37:08 -0600 (Fri, 07 Dec 2007) | 7 lines Hangups that happen during autoservice were not processed appropriately. This is because a hangup actually causes a NULL frame to be received, not a hangup frame. Queueing a hangup if we receive a NULL frame during autoservice corrects this problem (closes issue ASTERISK-10974, reported  by jmls, patched by me) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=91737 By: Digium Subversion (svnbot) 2007-12-07 09:38:09.000-0600 Repository: asterisk Revision: 91738 _U  trunk/ U   trunk/main/autoservice.c ------------------------------------------------------------------------ r91738 | mmichelson | 2007-12-07 09:38:08 -0600 (Fri, 07 Dec 2007) | 15 lines Merged revisions 91737 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r91737 | mmichelson | 2007-12-07 09:39:58 -0600 (Fri, 07 Dec 2007) | 7 lines Hangups that happen during autoservice were not processed appropriately. This is because a hangup actually causes a NULL frame to be received, not a hangup frame. Queueing a hangup if we receive a NULL frame during autoservice corrects this problem (closes issue ASTERISK-10974, reported  by jmls, patched by me) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=91738