[asterisk-bugs] [Asterisk 0010718]: ooh323 heap corruption every 3 days.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10718 
====================================================================== 
Reported By:                xrg
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10718
Category:                   Addons/chan_ooh323
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     new
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-14-2007 02:45 CDT
Last Modified:              09-27-2007 02:29 CDT
====================================================================== 
Summary:                    ooh323 heap corruption every 3 days.
Description: 
I have been experiencing a crash of asterisk every 2-3 days (given my
usage). Cores all suggest a heap corruption.

The data I collected so far shouldn't be that useful, I know. But any
suggestion you may have will be appreciated. Running with MALLOC_CHECK
should be my last resort, since the machine is a production one.
====================================================================== 

---------------------------------------------------------------------- 
 xrg - 09-27-07 02:29  
---------------------------------------------------------------------- 
Up: for the last 5 days, asterisk hasn't crashed (yet).
There is two new conditions: I've been running asterisk with
MALLOC_CHECK_=2
and my ISP's round trip times have drastically improved (from 150ms to 20
ms).

Malloc check means that I should have had an earlier crash, once the heap
is about to get double-freed.

Both conditions, however, mean that timing wrt. opening/closing threads
and unwanted timeouts have changed. I can still insist on the wild guess
that the data corruption is associated to return paths of the functions. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-27-07 02:29  xrg            Note Added: 0071141                          
======================================================================