[asterisk-bugs] [Asterisk 0010809]: Asterisk segfaults after an attended transfer to a queue using "Eyebeam" softphone.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10809 
====================================================================== 
Reported By:                Ted Brown
Assigned To:                dwaynemh
====================================================================== 
Project:                    Asterisk
Issue ID:                   10809
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             09-23-2007 16:13 CDT
Last Modified:              10-05-2007 08:01 CDT
====================================================================== 
Summary:                    Asterisk segfaults after an attended transfer to a
queue using "Eyebeam" softphone.
Description: 
Platform: Suse Linux Enterprise Server 10
Machine: IBM xSeries 226
Asterisk version: 1.4.11

Bug description:

Asterisk crashes (segfault) when an attended transfer to a queue is
performed and when EYEBEAM sofphone is used to make the transfer. This
crash can be easily reproduced as follows:

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0007706 Redirecting Local channels to Meetme ca...
====================================================================== 

---------------------------------------------------------------------- 
 Ted Brown - 10-05-07 08:01  
---------------------------------------------------------------------- 
Sorry, i have found no clear pattern to reproduce this. I have been testing
several ways, and I made it crash. But not a deterministic way. There must
be some factor I am not noticing. It will crash after an attended transfer,
sooner or later. And in the production machine there are dozens of
transfers during a day. You can try to duplicate it as I explained before,
with a transfer with an eyebeam to the same extension, and with the
configuration that I have already uploaded.

The difference between crashing or not crashing can be seen on the
console. When it doesn't crash it looks like this:

-- SIP/302-08238dd0 answered Local/302 at internal-1b3b,2
[Oct  5 14:58:38] DEBUG[10917]: app_queue.c:2166 wait_for_answer: Dunno
what to do with control type -1
    -- Agent/302 answered SIP/129-08232218
    -- Stopped music on hold on SIP/129-08232218
[Oct  5 14:58:38] DEBUG[10917]: chan_agent.c:538 agent_read: Bridge on
'SIP/302-08238dd0' being set to 'Agent/302' (3)
[Oct  5 14:58:38] DEBUG[10917]: chan_agent.c:446 agent_read: Native
formats changing from 4 to 524292
[Oct  5 14:58:38] DEBUG[10917]: chan_agent.c:446 agent_read: Resetting
read to 4 and write to 4
  == Spawn extension (internal, 302, 3) exited non-zero on
'Local/302 at internal-1b3b,2'
    -- Started music on hold, class 'default', on SIP/302-08238dd0
    -- Stopped music on hold on SIP/302-08238dd0
    -- Stopped music on hold on SIP/202-0822b098
[Oct  5 14:58:40] DEBUG[10664]: chan_sip.c:13026 attempt_transfer: SIP
transfer: Succeeded to masquerade channels.
[Oct  5 14:58:40] DEBUG[10855]: chan_agent.c:815 agent_hangup: Hungup,
howlong is 0, autologoff is 0
[Oct  5 14:58:40] DEBUG[10917]: chan_agent.c:461 agent_read: Bridge on
'Agent/129<ZOMBIE>' being cleared (2)
  == Spawn extension (departamento3, s, 4) exited non-zero on
'SIP/129-08232218'

When it crashes it never gets to show the 'Agent/XXX<ZOMBIE>' line(btw:
transferred:202, tranferer:129, transferee:302) 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-05-07 08:01  Ted Brown      Note Added: 0071521                          
======================================================================