[asterisk-bugs] [LibPRI 0017522]: segfault in pri_schedule_del - ctrl invalid value

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17522 
====================================================================== 
Reported By:                wuwu
Assigned To:                
====================================================================== 
Project:                    LibPRI
Issue ID:                   17522
Category:                   General
Reproducibility:            have not tried
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           Older 1.4 - please test a newer version 
JIRA:                        
libpri 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:             2010-06-17 13:44 CDT
Last Modified:              2010-06-18 12:38 CDT
====================================================================== 
Summary:                    segfault in pri_schedule_del - ctrl invalid value
Description: 
have had this crash for the first time. ctrl does have value 0x2 - so in
the while loop it does crash.

Short backtrace

(gdb) bt
https://issues.asterisk.org/view.php?id=0  0x0068f3a2 in pri_schedule_del
(ctrl=0x2, id=0) at prisched.c:178
https://issues.asterisk.org/view.php?id=1  0x00691be3 in stop_t303
(call=0xb53546d0) at q931.c:4726
https://issues.asterisk.org/view.php?id=2  0x00697930 in __q931_hangup
(ctrl=<value optimized out>, c=0xb53546d0,
cause=16) at q931.c:5445
https://issues.asterisk.org/view.php?id=3  0x00689ea8 in pri_hangup (pri=0x0,
call=0x2, cause=2) at pri.c:983
https://issues.asterisk.org/view.php?id=4  0x010130ed in dahdi_hangup
(ast=0xb5325848) at chan_dahdi.c:2991
https://issues.asterisk.org/view.php?id=5  0x0808562b in ast_hangup
(chan=0xb5325848) at channel.c:1522
https://issues.asterisk.org/view.php?id=6  0x080cf60e in __ast_pbx_run
(c=0xb5325848) at pbx.c:2576
https://issues.asterisk.org/view.php?id=7  0x080d017e in pbx_thread
(data=0xb5325848) at pbx.c:2636
https://issues.asterisk.org/view.php?id=8  0x080ffdab in dummy_start
(data=0xb5355fb8) at utils.c:856
https://issues.asterisk.org/view.php?id=9  0x009a35ab in start_thread () from
/lib/libpthread.so.0
https://issues.asterisk.org/view.php?id=10 0x008f9cfe in clone () from
/lib/libc.so.6

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

---------------------------------------------------------------------- 
 (0123608) wuwu (reporter) - 2010-06-18 12:38
 https://issues.asterisk.org/view.php?id=17522#c123608 
---------------------------------------------------------------------- 
we are using 1.4.24.1 - and are quit happy with it. We have had quite a lot
of version running - until we found this version which is stable - despite
of this bug.

I know - you need the latest version to be sure that there are no side
effects of memory corruption because of a bug in asterisk.

If the crash happens some more times - than i can surly have the customer
to agree on updating - else the customer doesn't want to update.

How safe would you consider an update from 1.4.24.1 to the latest 1.4.x 
stable on a production system (System is running with 2 four port digium
PRI cards - 6 lines connected - 240 DAHDI channels - 60 SIP channels on
high load - doing recording of each channel - and doing db lookups)

Load average is about 2, cpu utilization around 40%, io-wait does not
matter with around 0.1%.

Could it be that the load average of around 2 can cause problems ? System
would have place for anopther proc... (running on 1 E5440 - HP G6 DL360) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-06-18 12:38 wuwu           Note Added: 0123608                          
======================================================================