[asterisk-bugs] [Asterisk 0015314]: [patch] Seg fault in chan_local - local_pvt_destroy

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15314 
====================================================================== 
Reported By:                sroberts
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15314
Category:                   Channels/chan_local
Reproducibility:            unable to reproduce
Severity:                   crash
Priority:                   normal
Status:                     acknowledged
Target Version:             1.4.28
Asterisk Version:           1.4.22 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-06-11 04:50 CDT
Last Modified:              2009-08-19 12:33 CDT
====================================================================== 
Summary:                    [patch] Seg fault in chan_local - local_pvt_destroy
Description: 
This is the same issue as 14780. We also use SNOM phones (300s and 320s)
however these extensions are not connected to the server on which Asterisk
crashed. The crash occurred on the queue server.

A backtrace of the crash has been attached.

The crash here occurred when callfile finished execution. We use callfiles
to pause/unpause the agents. The local_pvt being freed is not null:

(gdb) frame 2
https://issues.asterisk.org/view.php?id=2  0x002dd837 in local_pvt_destroy
(pvt=0xa23e928) at chan_local.c:159
159             free(pvt);
(gdb) p pvt
$1 = (struct local_pvt *) 0xa23e928
(gdb) p *pvt
$2 = {lock = {mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0,
__m_kind = 1, __m_lock = {__status = 0, __spinlock = 0}}, track = 1, file =
{0x2e0f08 "chan_local.c", 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
lineno = {158, 0, 0, 0, 0, 0, 0, 0, 0, 0}, reentrancy = 0, func = {0x2e0fbe
"local_pvt_destroy", 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, thread =
{0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, reentr_mutex = {__m_reserved = 0, __m_count
= 0, __m_owner = 0x0, __m_kind = 1, __m_lock = {__status = 0, __spinlock =
0}}}, flags = 16, context = "vital-out", '\0' <repeats 70 times>, exten =
"*\000vital-out\000n", '\0' <repeats 66 times>, reqformat = 64, owner =
0x0, chan = 0x0, u_owner = 0xa2234c8, u_chan = 0xa1c3500, list = {next =
0x0}}


Due to the fact that our queue servers are so busy I cannot simply upgrade
it to a newer version (this one in particular handles around 10000 calls
per day) unless I know a version is stable. I've tested 1.4.25 and it
proved horrendously unstable (deadlocks and seg faults).


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0014780 Asterisk abort (signal 6) in local_pvt_...
====================================================================== 

---------------------------------------------------------------------- 
 (0109277) davidw (reporter) - 2009-08-19 12:33
 https://issues.asterisk.org/view.php?id=15314#c109277 
---------------------------------------------------------------------- 
This breakpoint didn't trip, which contra-indicates the theory that
IS_OUTBOUND was confused, at least in this case:

2   breakpoint     keep y   0x002f55c0 in local_hangup at
chan_local.c:609
        stop only if !p->owner

However, a simple, two party, collision can, with the right timing result
in the re-lock in the DEADLOCK_AVOIDANCE failing and subsequent processing
on the private structure being invalid.  I don't think this accounts for
the failure on the earlier, explicit, lock on p, so I think I still have at
least one more thing to discover.  Unfortunately setting breakpoints
distorts the timing.

I come back to the question, is there a reason for setting p->owner null
before trying for the lock on p->chan?  That may be the easiest way to
avoid this variant. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-19 12:33 davidw         Note Added: 0109277                          
======================================================================