Summary:ASTERISK-12356: new added function queue_transfer_fixup crashes asterisk
Reporter:Martin Vit (festr)Labels:
Date Opened:2008-07-10 07:17:45Date Closed:2008-12-16 10:04:44.000-0600
Versions:Frequency of
Environment:Attachments:( 0) bt.txt
( 1) bt2.txt
Description:i've not enough time to try to reproduce it but on one productino system after upgrade to 1.4.21 asterisk crashed several times per day. (they use queues and agents with local channels) See attached backtrace bt.txt
Comments:By: Sean Bright (seanbright) 2008-07-10 07:32:20

There is no function named queue_transfer_fixup in app_queue.c in Asterisk 1.4.21

By: Sean Bright (seanbright) 2008-07-10 07:36:30

Updated to reflect the correct version of asterisk where there is a problem and reopened.

By: Sean Bright (seanbright) 2008-07-10 07:41:48

Can you please execute the following command and report back the output:

   asterisk -rx "core show version"

By: Martin Vit (festr) 2008-07-10 08:01:33

SVN-branch-1.4-r127663M (Modified because i've commented some debug levels out)

I've also searched right revision number, where this function was added: 125530 (Backport of attended transfer queue_log patch from trunk.)

By: Sean Bright (seanbright) 2008-07-10 08:10:34

There are 200 additional lines in your version of app_queue according to the backtrace you submitted, which wouldn't happen if you had just commented out some debug logging.

If you can get us a backtrace using an unmodified version of app_queue, we will be happy to look at it.

Also, instead of commenting out debugging, just run "core set debug 0" at the CLI and it won't show up.

By: Martin Vit (festr) 2008-07-10 08:45:47

Ok, it will take me some time, i've to prepare test environment and reproduce this bug and do deeper analysys on vanilla asterisk version. I though it would be easear :-)

I've own patches which adds czech localization to app_queue.c I apologize not mentioning it (it is irrelevant to this bug).

By: Sean Bright (seanbright) 2008-07-10 09:18:22

Please re-open when you have this problem with an unpatched version.

By: Michiel van Baak (mvanbaak) 2008-07-15 07:26:35

Reopened as requested by festr on #asterisk-dev

By: Martin Vit (festr) 2008-07-15 08:40:33

I'm able to reproduce it now on clean asterisk version

asterisk  -rx'show version': Asterisk SVN-branch-1.4-r130889 built by root @ virtual1 on a i686 running Linux on 2008-07-15 11:07:36 UTC

Scenario how to reproduce:

three SIP phones (A,B,C)
queue with member Local/510@mytest where [mytest] exten => 510,1,Dial(SIP/B,,tT)

call from SIP/A to app_queue -> member Local/510@mytest -> SIP(B). answer(B) -> do SIP bling transfer (or builtin transfer #) to SIP/C and answer C, next do built-in attendand transfer *2 on SIP/C back to SIP/B and hangup SIP/C before SIP/B answer -> Core dump. See bt2.txt (in the backtrace SIP/a217 equels to SIP/A, SIP/test eq. to SIP/B and SIP/a218 eq. to SIP/C

I'm not able to reproduce it when using only blind transfers or only attendand trasfers. It crashes everytime when I do blind trasnfer from queue to another phone and from here do attendand transfer to another phone (but you have to hangup during attendand (ringing) before the other end answer).

I've also reduce dialplan to minimal. Using only two applications, Queue and Dial.

Hope, that this help. I'll keep this virtual box for testing.

By: Mark Michelson (mmichelson) 2008-07-15 09:37:11

Thank you for outlining the situation very clearly. I will attempt to reproduce it here and get a fix merged.

By: Digium Subversion (svnbot) 2008-07-16 13:49:45

Repository: asterisk
Revision: 131299

U   branches/1.4/apps/app_queue.c

r131299 | mmichelson | 2008-07-16 13:49:44 -0500 (Wed, 16 Jul 2008) | 13 lines

Make absolutely certain that the transfer datastore
is removed from the calling channel once the caller
is finished in the queue. This could have weird con-
sequences when dialing local queue members when multiple
transfers occur on a single call.

Also fixed a memory leak that would occur when an
attended transfer occurred from a queue member.

(closes issue ASTERISK-12356)
Reported by: festr