[asterisk-bugs] [LibPRI 0014335]: Crash on pri_schedule_event - t200_expire

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14335 
====================================================================== 
Reported By:                ricvil
Assigned To:                mattf
====================================================================== 
Project:                    LibPRI
Issue ID:                   14335
Category:                   General
Reproducibility:            random
Severity:                   crash
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.22 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2009-01-26 10:56 CST
Last Modified:              2009-05-31 11:26 CDT
====================================================================== 
Summary:                    Crash on pri_schedule_event - t200_expire
Description: 
I have had multiple crashes using libpri 1.4.7 (see
http://bugs.digium.com/view.php?id=14243).

I now upgraded to libpri 1.4.9 (same Asterisk 1.4.22) and the issue still
happens.  Compiled with DONT_OPTIMIZE, DEBUG_CHANNEL_LOCK, and
DEBUG_THREADS

Here is the latest crash from today:
Program terminated with signal 11, Segmentation fault.
https://issues.asterisk.org/view.php?id=0  0x009d6ce2 in pri_schedule_event
(pri=0x12, ms=0, function=0x9d43a4
<t200_expire>, data=0xb7a502e0) at prisched.c:44
44              while (pri->master)

(gdb) bt
https://issues.asterisk.org/view.php?id=0  0x009d6ce2 in pri_schedule_event
(pri=0x12, ms=0, function=0x9d43a4
<t200_expire>, data=0xb7a502e0) at prisched.c:44
https://issues.asterisk.org/view.php?id=1  0x009d3c0f in reschedule_t200
(pri=0xb7a502e0) at q921.c:259
https://issues.asterisk.org/view.php?id=2  0x009d4ba7 in q921_transmit_iframe
(pri=0xb7a502e0, buf=0x5725b50,
len=9, cr=1) at q921.c:537
https://issues.asterisk.org/view.php?id=3  0x009dd489 in q931_xmit
(pri=0xb7a502e0, h=0x5725b50, len=9, cr=1) at
q931.c:2611
https://issues.asterisk.org/view.php?id=4  0x009dd682 in send_message
(pri=0xb7d73540, c=0xb7a383a0, msgtype=69,
ies=0x9f501c) at q931.c:2654
https://issues.asterisk.org/view.php?id=5  0x009de935 in q931_disconnect
(pri=0xb7d73540, c=0xb7a383a0, cause=16)
at q931.c:3020
https://issues.asterisk.org/view.php?id=6  0x009df2a3 in q931_hangup
(pri=0xb7d73540, c=0xb7a383a0, cause=16) at
q931.c:3230
https://issues.asterisk.org/view.php?id=7  0x009d2693 in pri_hangup
(pri=0xb7d73540, call=0xb7a383a0, cause=16)
at pri.c:623
https://issues.asterisk.org/view.php?id=8  0x012e9851 in dahdi_hangup
(ast=0xb7a0b9a8) at chan_dahdi.c:2718
https://issues.asterisk.org/view.php?id=9  0x08087ae3 in ast_hangup
(chan=0xb7a0b9a8) at channel.c:1507
https://issues.asterisk.org/view.php?id=10 0x080d6245 in __ast_pbx_run
(c=0xb7a0b9a8) at pbx.c:2561
https://issues.asterisk.org/view.php?id=11 0x080d6495 in pbx_thread
(data=0xb7a0b9a8) at pbx.c:2621
https://issues.asterisk.org/view.php?id=12 0x08119e13 in dummy_start
(data=0xb7a6d360) at utils.c:912
https://issues.asterisk.org/view.php?id=13 0x0067946b in start_thread () from
/lib/libpthread.so.0
https://issues.asterisk.org/view.php?id=14 0x005d0dbe in clone () from
/lib/libc.so.6
(gdb) 

I will attach the full backtrace on file backtrace1.txt
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014243 core dump on pri_schedule_event
====================================================================== 

---------------------------------------------------------------------- 
 (0105817) ricvil (reporter) - 2009-05-31 11:26
 https://issues.asterisk.org/view.php?id=14335#c105817 
---------------------------------------------------------------------- 
I have found a workaround that eliminates the cause of this crash.  I
noticed that the crash was happening right after the hourly 'B-channel X/X
successfully restarted on span 3'.  It turns out that since span 3 and 4
are looped together, there is a chance that Span 3 or Span 4 gives the
order to reset a channel that is currently in use and somewhere along the
line the crash happens.  If I disable channel restarts, the problem
disappears completely.  The bug is still there but at least it won't affect
this specific setup. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-31 11:26 ricvil         Note Added: 0105817                          
======================================================================