[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:24 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0106633) svnbot (reporter) - 2009-06-18 10:24
 https://issues.asterisk.org/view.php?id=15109#c106633 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 201600

U   branches/1.4/res/res_musiconhold.c

------------------------------------------------------------------------
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=201600 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-18 10:24 svnbot         Note Added: 0106633                          
======================================================================