[Home]

Summary:ASTERISK-05305: GROUP_COUNT inconsistencies
Reporter:Ryan D (icemaann)Labels:
Date Opened:2005-10-17 21:37:20Date Closed:2011-06-07 14:10:43
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Functions/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When calling NoOp(${GROUP_COUNT(TEST)}) before and after a call to Set(GROUP()=TEST) GROUP_COUNT(TEST) returns 0. The next call to Set(GROUP()=TEST) will make GROUP_COUNT(TEST) return 1. This is fine, except that it behaves differently when doing a transfer. When doing a transfer the 1st call to GROUP()=TEST2 will make GROUP_COUNT(TEST2) return 1. This is best explained using an example dialplan. Using my example dialplan have someone dial extension 4000 (and make sure it is answered). Then do a transfer (*2, #1, etc) to extension 5000.

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

exten => 4000,1,NoOp(${GROUP_COUNT(TEST)})
exten => 4000,n,Set(GROUP()=TEST)
exten => 4000,n,NoOp(${GROUP_COUNT(TEST)}) ; This will return 0
exten => 4000,n,Dial(IAX2/goiax/1XXXXXXXXXX,20,tT)

exten => 5000,1,NoOp(${GROUP_COUNT(TEST2)})
exten => 5000,n,Set(GROUP()=TEST2)
exten => 5000,n,NoOp(${GROUP_COUNT(TEST2)}) ; This will return 1
exten => 5000,n,Dial(SIP/1XXXXXXXXXX@vbuzzer:80,999,Tt)
Comments:By: Ryan D (icemaann) 2005-10-17 21:48:27

I mistakenly filed this under Function Core rather than New Functions.
By: Mark Spencer (markster) 2005-10-17 22:32:00

I cut and paste your example for 4000 and did not have the experience you described:

   -- Executing NoOp("Zap/25-1", "0") in new stack
   -- Executing Set("Zap/25-1", "GROUP()=TEST") in new stack
Oct 17 22:32:40 DEBUG[4299]: pbx.c:1527 pbx_substitute_variables_helper_full: Function result is '1'
   -- Executing NoOp("Zap/25-1", "1") in new stack

Also tried from oss:

   -- Executing NoOp("OSS/dsp", "0") in new stack
   -- Executing Set("OSS/dsp", "GROUP()=TEST") in new stack
Oct 17 22:31:58 DEBUG[4296]: pbx.c:1527 pbx_substitute_variables_helper_full: Function result is '1'
   -- Executing NoOp("OSS/dsp", "1") in new stack                              

What am I missing?  I'm using latest CVS head.
By: Ryan D (icemaann) 2005-10-17 23:38:13

Here is the output from mine (1.2beta1):

   -- Executing NoOp("SIP/3002-e9a1", "0") in new stack
   -- Executing Set("SIP/3002-e9a1", "GROUP()=TEST") in new stack
Oct 17 20:25:51 WARNING[3383]: channel.c:709 channel_find_locked: Avoided initial deadlock for '0x8a59768', 10 retries!
   -- Executing NoOp("SIP/3002-e9a1", "0") in new stack
   -- Executing Dial("SIP/3002-e9a1", "IAX2/goiax/1208XXXXXXX|20|tT") in new stack
   -- Called goiax/1208XXXXXXX
   -- Call accepted by 204.13.233.114 (format ulaw)
   -- Format for call is ulaw
   -- IAX2/goiax-2 is making progress passing it to SIP/3002-e9a1
   -- IAX2/goiax-2 answered SIP/3002-e9a1
   -- Started music on hold, class 'default', on channel 'IAX2/goiax-2'
   -- Playing 'pbx-transfer' (language 'en')
Oct 17 20:26:06 WARNING[3383]: channel.c:709 channel_find_locked: Avoided deadlock for '0x8a5dd80', 10 retries!
   -- Executing NoOp("Local/5000@nothome-aae0,2", "0") in new stack
   -- Executing Set("Local/5000@nothome-aae0,2", "GROUP()=TEST2") in new stack
Oct 17 20:26:06 WARNING[3383]: channel.c:709 channel_find_locked: Avoided deadlock for '0x8a5dd80', 10 retries!
   -- Executing NoOp("Local/5000@nothome-aae0,2", "1") in new stack
   -- Executing Dial("Local/5000@nothome-aae0,2", "SIP/1208XXXXXXX@vbuzzer:80|999|Tt") in new stack
   -- Called 1208XXXXXXX@vbuzzer:80
   -- SIP/vbuzzer:80-5cdd is ringing
   -- Local/5000@nothome-aae0,1 is ringing



I can try CVS head in the next couple of days (I will also run it with debug output tomorrow). I noticed mine has deadlock warnings. Hopefully I can help track this down.
By: Mark Spencer (markster) 2005-10-17 23:47:23

Clearly here the problem is the apparent deadlock on the channel:
Oct 17 20:25:51 WARNING[3383]: channel.c:709 channel_find_locked: Avoided initial deadlock for '0x8a59768', 10 retries!
By: Ryan D (icemaann) 2005-10-21 19:45:22

I upgraded to CVS HEAD today and Im still seeing the "Avoided initial deadlock" errors. This is on CentOS 3.5 with gcc 3.2.3. I tried this on a debian testing box and I could not recreate the issue. I can send more details if needed (ldd, traces, etc) otherwise I will update the OS and libraries and see if that fixes it.

What are the next steps you want me to take?
By: Mark Spencer (markster) 2005-10-23 14:07:53

Please find me on IRC so I can login to the system having the issue and do a backtrace plus attach and see what might be holding the channel lock.
By: Mark Spencer (markster) 2005-10-25 00:32:07

Just an issue with debian, only occurs in old debian with -p flag...