[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:                     new
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-14 11:29 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_...
====================================================================== 

---------------------------------------------------------------------- 
 (0109051) davidw (reporter) - 2009-08-14 11:29
 https://issues.asterisk.org/view.php?id=15314#c109051 
---------------------------------------------------------------------- 
In our case, using 1.6.1.0, with the
https://issues.asterisk.org/view.php?id=14780 patch in, the problem has to
arise in the following lines:

599 :     		p->chan = NULL;
600 :     		ast_clear_flag(p, LOCAL_LAUNCHED_PBX);
601 :     		ast_module_user_remove(p->u_chan);
602 :     	} else {
603 :     		p->owner = NULL;
604 :     		ast_module_user_remove(p->u_owner);
605 :     		while (p->chan && ast_channel_trylock(p->chan)) {
606 :     			DEADLOCK_AVOIDANCE(&p->lock);
607 :     		}
608 :     		if (p->chan) {
609 :     			ast_queue_hangup(p->chan);
610 :     			ast_channel_unlock(p->chan);
611 :     		}
612 :     	}
613 :     	
614 :     	ast->tech_pvt = NULL;

This is because both owner and chan are null, but the owner side tech_pvt
isn't.  It pretty much has to be the DEADLOCK_AVOIDANCE.  It is temporarily
releasing the lock on the private structure.

Is there any good reason, except possibly a misguided attempt to factor
out common code, for the clearing of tech_pvt not to be done immediately
after the clearing of the owner/chan?

Although this is the only place where that combination can occur, I still
cannot explain how local hangup can get re-entered on the owner channel
without a recursive call on the stack.... 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-14 11:29 davidw         Note Added: 0109051                          
======================================================================