[asterisk-bugs] [Asterisk 0015109]: Abort by memory allocator, possibly in moh_files_generator

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15109 
====================================================================== 
Reported By:                jvandal
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15109
Category:                   Resources/res_musiconhold
Reproducibility:            random
Severity:                   block
Priority:                   normal
Status:                     acknowledged
Target Version:             1.4.27
Asterisk Version:           1.4.24 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-05-14 10:49 CDT
Last Modified:              2009-06-18 10:40 CDT
====================================================================== 
Summary:                    Abort by memory allocator, possibly in
moh_files_generator
Description: 
I have a server running with Asterisk 1.4.24.1 where it randomly segfault
for "unknown" reason.

I'm not sure if this is related to moh_files_generator function or with
filestream_descructor.

Let me know what needed in order to fix this crash, if GDB traces aren't
enough. 

Asterisk is compiled with DONT_OPTIMIZE and others flag needed for "gdb".

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014958 Segfault Asterisk 1.4.24.1
related to          0015123 out of bounds crash and core dump
has duplicate       0015195 double free or corruption (!prev) in mo...
====================================================================== 

---------------------------------------------------------------------- 
 (0106650) svnbot (reporter) - 2009-06-18 10:40
 https://issues.asterisk.org/view.php?id=15109#c106650 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 201614

_U  branches/1.6.2/
U   branches/1.6.2/res/res_musiconhold.c

------------------------------------------------------------------------
r201614 | russell | 2009-06-18 10:40:16 -0500 (Thu, 18 Jun 2009) | 43
lines

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

................
  r201610 | russell | 2009-06-18 10:27:10 -0500 (Thu, 18 Jun 2009) | 36
lines
  
  Merged revisions 201600 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r201600 | russell | 2009-06-18 10:24:31 -0500 (Thu, 18 Jun 2009) | 29
lines
    
    Fix memory corruption and leakage related reloads of non files mode
MoH classes.
    
    For Music on Hold classes that are not files mode, meaning that we are
executing
    an application that will feed us audio data, we use a thread to
monitor the
    external application and read audio from it.  This thread also makes
use of the
    MoH class object.  In the MoH class destructor, we used
pthread_cancel() to ask
    the thread to exit.  Unfortunately, the code did not wait to ensure
that the
    thread actually went away.  What needed to be done is a pthread_join()
to ensure
    that the thread fully cleans up before we proceed.  By adding this one
line, we
    resolve two significant problems:
    
      1) Since the thread was never joined, it never fully goes away.  So,
on every
         reload of non-files mode MoH, an unused thread was sticking
around.
    
      2) There was a race condition here where the application monitoring
thread
         could still try to access the MoH class, even though the thread
executing
         the MoH reload has already destroyed it.
    
    (issue https://issues.asterisk.org/view.php?id=15109)
    Reported by: jvandal
    
    (issue https://issues.asterisk.org/view.php?id=15123)
    Reported by: axisinternet
    
    (issue https://issues.asterisk.org/view.php?id=15195)
    Reported by: amorsen
    
    (issue AST-208)
  ........
................

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-18 10:40 svnbot         Checkin                                      
2009-06-18 10:40 svnbot         Note Added: 0106650                          
======================================================================