[asterisk-bugs] [Asterisk 0016374]: Crash due to fault about twice daily

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16374 
====================================================================== 
Reported By:                hevad
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16374
Category:                   Core/General
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 232348 
Request Review:              
====================================================================== 
Date Submitted:             2009-12-02 12:05 CST
Last Modified:              2009-12-07 13:22 CST
====================================================================== 
Summary:                    Crash due to fault about twice daily
Description: 
Asterisk crashes sporadically about one or twice per day. back trace always
very similar:

(gdb) bt full
https://issues.asterisk.org/view.php?id=0  0x00002ab0b3dd2265 in raise () from
/lib64/libc.so.6
No symbol table info available.
https://issues.asterisk.org/view.php?id=1  0x00002ab0b3dd3d10 in abort () from
/lib64/libc.so.6
No symbol table info available.
https://issues.asterisk.org/view.php?id=2  0x00002ab0b3e0c84b in __libc_message
() from /lib64/libc.so.6
No symbol table info available.
https://issues.asterisk.org/view.php?id=3  0x00002ab0b3e142ef in _int_free ()
from /lib64/libc.so.6
No symbol table info available.
https://issues.asterisk.org/view.php?id=4  0x00002ab0b3e1473b in free () from
/lib64/libc.so.6
No symbol table info available.
https://issues.asterisk.org/view.php?id=5  0x0000000000496f29 in
frame_cache_cleanup (data=0x1caf4220) at
frame.c:325
        frames = (struct ast_frame_cache *) 0x1caf4220
        f = (struct ast_frame *) 0x1cae7030
https://issues.asterisk.org/view.php?id=6  0x00002ab0b4303ac9 in
__nptl_deallocate_tsd () from
/lib64/libpthread.so.0
No symbol table info available.
https://issues.asterisk.org/view.php?id=7  0x00002ab0b43044b5 in start_thread ()
from /lib64/libpthread.so.0
No symbol table info available.
https://issues.asterisk.org/view.php?id=8  0x00002ab0b3e75c2d in clone () from
/lib64/libc.so.6
No symbol table info available.


====================================================================== 

---------------------------------------------------------------------- 
 (0114866) hevad (reporter) - 2009-12-07 13:22
 https://issues.asterisk.org/view.php?id=16374#c114866 
---------------------------------------------------------------------- 
I modified the source such that the backtrace would indicate where the
frame was allocated that caused the heap to crash with this result:

5  0x0000000000496f89 in frame_cache_cleanup (data=0x1398a980) at
frame.c:326
        src = 0x12d5bd50 "ulawtolin"
        frames = (struct ast_frame_cache *) 0x1398a980
        f = (struct ast_frame *) 0x12d5bb60

Which indicates the problem frame is allocated in ulawtolin for some
reason. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-07 13:22 hevad          Note Added: 0114866                          
======================================================================