[asterisk-bugs] [Asterisk 0016470]: 'core stop when convenient' causes segfault

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16470 
====================================================================== 
Reported By:                kjotte
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16470
Category:                   General
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.2.0 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-12-18 21:17 CST
Last Modified:              2009-12-20 17:39 CST
====================================================================== 
Summary:                    'core stop when convenient' causes segfault
Description: 
Freshly compiled 1.6.2.0 segfaults every time 'core stop when convenient'
is executed.  Also intermittent crashes at other times, but cannot stably
reproduce.
====================================================================== 

---------------------------------------------------------------------- 
 (0115489) nic_bellamy (reporter) - 2009-12-20 17:39
 https://issues.asterisk.org/view.php?id=16470#c115489 
---------------------------------------------------------------------- 
I have the same thing on 1.6.1.11/1.6.1.12, but hadn't filed a bug report
yet as I was still doing some digging on my own when I saw this.

My digging through the source appears to show that chan_iax2 still has an
open timer at the point res_timing_dahdi unregisters it; a run through
valgrind confirms this:

==5049== Thread 28:
==5049== Invalid read of size 4
==5049==    at 0x8144F0C: ast_timer_ack (timing.c:169)
==5049==    by 0x1C220A00: ??? (chan_iax2.c:8690)
==5049==    by 0x80DEF16: ast_io_wait (io.c:288)
==5049==    by 0x1C22E683: ??? (chan_iax2.c:11615)
==5049==    by 0x814E47E: dummy_start (utils.c:968)
==5049==    by 0x1BB87E50: pthread_start_thread (manager.c:309)
==5049==    by 0x1BB1C8A9: clone (clone.S:102)
==5049==  Address 0x1BC866E8 is 8 bytes inside a block of size 12 free'd
==5049==    at 0x1B904B04: free (vg_replace_malloc.c:152)
==5049==    by 0x8144D24: ast_unregister_timing_interface (timing.c:111)
==5049==    by 0x1F91303E: ??? (res_timing_dahdi.c:196)
==5049==    by 0x80E1169: ast_module_shutdown (loader.c:459)
==5049==    by 0x80726F4: quit_handler (asterisk.c:1390)
==5049==    by 0x8072E48: handle_stop_when_convenient (asterisk.c:1665)
==5049==    by 0x8072E84: handle_stop_when_convenient_deprecated
(asterisk.c:1671)
==5049==    by 0x809EF9C: ast_cli_command (cli.c:1888)
==5049==    by 0x8072A6E: consolehandler (asterisk.c:1536)
==5049==    by 0x807770A: main (asterisk.c:3543)

I can't see any form of refcounting in main/timing.c - so
ast_unregister_timing_interface() happily runs off and frees a timer that
still has users. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-20 17:39 nic_bellamy    Note Added: 0115489                          
======================================================================