[asterisk-bugs] [Asterisk 0013802]: manager core dumps after 45, 000 AMI originates

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13802 
====================================================================== 
Reported By:                hubbaba
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13802
Category:                   Core/ManagerInterface
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.0.1 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-10-29 14:29 CDT
Last Modified:              2008-10-30 15:26 CDT
====================================================================== 
Summary:                    manager core dumps after 45,000 AMI originates
Description: 
I have a Java GatewayDriver that links ami to agi for outbound calls.  Each
call lasts 10 seconds (stream 2 (5 second) files via fast-agi).  After
45,000 calls (2 hours of processing 90 simultaneous calls on 4 PRI spans),
Asterisk proceeds to core dump.  

I opened the core in gdb.  The segmentation fault is occurring in
manager.c on line 2385.  s->last_ev is NULL for some reason and the
NEW_EVENT calls AST_LIST_NEXT which then fails because it tries to
dereference s->last_ev.  

I have a 62MB core file if anyone is interested in looking through it.  

Thank you for your help!  I really appreciate it!
====================================================================== 

---------------------------------------------------------------------- 
 (0094441) hubbaba (reporter) - 2008-10-30 15:26
 http://bugs.digium.com/view.php?id=13802#c94441 
---------------------------------------------------------------------- 
Wish I could.  I just put business edition on a few hours ago.  I want to
see if the bug occurs in BE.  Here is the bt full (I know it doesn't help
much without turning off optimization):

(gdb) bt full
http://bugs.digium.com/view.php?id=0  0x080d113a in process_events (s=0x839c160)
at manager.c:2388
	eqe = (struct eventqent *) 0x1
	ret = 138002788
http://bugs.digium.com/view.php?id=1  0x080dabf1 in do_message (s=0x839c164) at
manager.c:2865
	m = {hdrcount = 0, headers = {0x0 <repeats 128 times>}}
	header_buf = '\0' <repeats 1024 times>
	res = <value optimized out>
http://bugs.digium.com/view.php?id=2  0x080db0a7 in session_do (data=0xb7b1c100)
at manager.c:2928
	s = <value optimized out>
	flags = <value optimized out>
	res = <value optimized out>
	__PRETTY_FUNCTION__ = "session_do"
http://bugs.digium.com/view.php?id=3  0x0812e1db in dummy_start
(data=0xb7b2a990) at utils.c:898
	__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {-1213082520, 
        0, -1248081008, -1248082984, 596050069, 834898414}, 
      __mask_was_saved = 0}}, __pad = {0xb59bc490, 0x0, 0xb59bc3d4, 
    0xb7f72ff4}}
	__cancel_arg = (void *) 0xb59bcb90
	not_first_call = <value optimized out>
	ret = <value optimized out>
http://bugs.digium.com/view.php?id=4  0xb7e104fb in ?? ()
No symbol table info available.
http://bugs.digium.com/view.php?id=5  0xb7efee5e in ?? ()
---Type <return> to continue, or q <return> to quit---
No symbol table info available.
(gdb) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-30 15:26 hubbaba        Note Added: 0094441                          
======================================================================