[asterisk-bugs] [Asterisk 0015817]: crash in local_attended_transfer, likely related to moh - 1.4.26.1

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15817 
====================================================================== 
Reported By:                zerohalo
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   15817
Category:                   Channels/chan_sip/Transfers
Reproducibility:            sometimes
Severity:                   crash
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.26.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-09-02 09:42 CDT
Last Modified:              2009-10-08 15:03 CDT
====================================================================== 
Summary:                    crash in local_attended_transfer, likely related to
moh - 1.4.26.1
Description: 
Reopening this as new. Attended SIP transfer from Polycom UA, no queue
involved.

backtrace attached.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015845 Crash during attended transfer occurs
related to          0015609 [patch] WARNING[23025]: channel.c:952 _...
====================================================================== 

---------------------------------------------------------------------- 
 (0112079) svnbot (reporter) - 2009-10-08 15:03
 https://issues.asterisk.org/view.php?id=15817#c112079 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 222883

_U  branches/1.6.2/
U   branches/1.6.2/include/asterisk/file.h
U   branches/1.6.2/include/asterisk/frame.h
U   branches/1.6.2/main/file.c
U   branches/1.6.2/main/frame.c

------------------------------------------------------------------------
r222883 | russell | 2009-10-08 15:03:42 -0500 (Thu, 08 Oct 2009) | 58
lines

Merged revisions 222880 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r222880 | russell | 2009-10-08 14:52:03 -0500 (Thu, 08 Oct 2009) | 51
lines
  
  Merged revisions 222878 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r222878 | russell | 2009-10-08 14:45:47 -0500 (Thu, 08 Oct 2009) | 44
lines
    
    Make filestream frame handling safer by isolating frames before
returning them.
    
    This patch is related to a number of issues on the bug tracker that
show
    crashes related to freeing frames that came from a filestream.  A
number of
    fixes have been made over time while trying to figure out these
problems, but
    there re still people seeing the crash.  (Note that some of these bug
reports
    include information about other problems.  I am specifically
addressing
    the filestream frame crash here.)
    
    I'm still not clear on what the exact problem is.  However, what is
_very_
    clear is that we have seen quite a few problems over time related to
unexpected
    behavior when we try to use embedded frames as an optimization.  In
some cases,
    this optimization doesn't really provide much due to improvements made
in other
    areas.
    
    In this case, the patch modifies filestream handling such that the
embedded frame
    will not be returned.  ast_frisolate() is used to ensure that we end
up with a
    completely mallocd frame.  In reality, though, we will not actually
have to malloc
    every time.  For filestreams, the frame will almost always be
allocated and freed
    in the same thread.  That means that the thread local frame cache will
be used.
    So, going this route doesn't hurt.
    
    With this patch in place, some people have reported success in not
seeing the
    crash anymore.
    
    (SWP-150)
    (AST-208)
    (ABE-1834)
    
    (issue https://issues.asterisk.org/view.php?id=15609)
    Reported by: aragon
    Patches:
          filestream_frisolate-1.4.diff2.txt uploaded by russell (license
2)
    Tested by: aragon, russell
    
    (closes issue https://issues.asterisk.org/view.php?id=15817)
    Reported by: zerohalo
    Tested by: zerohalo
    
    (closes issue https://issues.asterisk.org/view.php?id=15845)
    Reported by: marhbere
    
    Review: https://reviewboard.asterisk.org/r/386/
  ........
................

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-08 15:03 svnbot         Checkin                                      
2009-10-08 15:03 svnbot         Note Added: 0112079                          
======================================================================