[Home]

Summary:ASTERISK-12769: exten = 2813,n, Queue(test,c,,,,,,inqueue) craches when went into invalid extension
Reporter:Fredrik Liljegren (fiddur)Labels:
Date Opened:2008-09-24 03:11:21Date Closed:2008-12-03 12:37:42.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:With empty [default] context and no context set for queue test, I had this in context [local_phones]:

exten = 2813,1, Answer
exten = 2813,n, Queue(test,c,,,,,,inqueue)
exten = 2813,n, Hangup

exten = 2813,n(inqueue), NoOp(Call taken by ${MEMBERINTERFACE})
exten = 2813,n, Return

Yes, that's a misinterpretation of the gosub-statement, I have realised.
When a call came into 2813, and answered by a queuemember, asterisk shuts down silently:

   -- Executing [2813@local_phones:1] Answer("SIP/3004-082b9b10", "") in new stack
   -- Executing [2813@local_phones:2] Queue("SIP/3004-082b9b10", "test,c,,,,,,inqueue") in new stack
   -- Started music on hold, class 'default', on SIP/3004-082b9b10
   -- SIP/3010-082bf340 is ringing
c042*CLI>
Disconnected from Asterisk server
Executing last minute cleanups
Asterisk ending (0).


The first time it happened, I also got:
[2008-09-24 09:41:20] WARNING[23423] pbx.c: Channel 'SIP/3003-b816e6d0' sent into invalid extension 's' in context 'default', but no invalid handler


****** ADDITIONAL INFORMATION ******

Tested both in 1.6.0-rc6 and svn branch 1.6.0 revision: 143608
Comments:By: Mark Michelson (mmichelson) 2008-09-24 13:41:03

I have reproduced this issue on my test setup. I'm not certain if the problem resides in app_queue or app_stack at this point, though. I will update as things become more clear.
By: Digium Subversion (svnbot) 2008-12-03 11:07:04.000-0600

Repository: asterisk
Revision: 160555

U   trunk/apps/app_queue.c

------------------------------------------------------------------------
r160555 | mmichelson | 2008-12-03 11:07:04 -0600 (Wed, 03 Dec 2008) | 11 lines

When investigating issue ASTERISK-12769, I found that gosub
handling in app_queue was just completely wrong, mostly
because the channel operations being performed were being
done on the incorrect channel.

With this set of changes, a gosub will correctly run on
the answering queue member's channel. There are still crash
issues which occur if there are dialplan syntax errors, so
I cannot yet close the referenced issue.


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=160555
By: Digium Subversion (svnbot) 2008-12-03 12:37:41.000-0600

Repository: asterisk
Revision: 160626

U   trunk/apps/app_dial.c
U   trunk/apps/app_queue.c
U   trunk/apps/app_stack.c

------------------------------------------------------------------------
r160626 | mmichelson | 2008-12-03 12:37:41 -0600 (Wed, 03 Dec 2008) | 16 lines

Add some safety measures when using gosub, especially when using the options
for app_dial and app_queue to run a gosub when the call is answered.

* Check for the existence of the gosub target in gosub_exec. If it is nonexistent,
 then this will cause errors when we attempt to actually run the gosub, including
 a definite memory leak and potential crashes. Return an error in this situation
* Check the return value of pbx_exec in app_dial and app_queue before attempting
 to actually run the gosub routine. If there was an error, we should not attempt
 to run the gosub.
* Change a '|' to a ',' in app_queue.
* Add some extra curly braces where they had been missing previously.

(closes issue ASTERISK-12769)
Reported by: fiddur


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=160626