[asterisk-dev] murf: branch 1.4 r152535 - in /branches/1.4: apps/ funcs/ include/asterisk/ res/

Russell Bryant russell at digium.com
Thu Oct 30 12:27:42 CDT 2008


SVN commits to the Digium repositories wrote:
> Author: murf
> Date: Tue Oct 28 23:36:32 2008
> New Revision: 152535
> 
> URL: http://svn.digium.com/view/asterisk?view=rev&rev=152535
> Log:
> The magic trick to avoid this crash is not to
> try to find the channel by name in the list,
> which is slow and resource consuming, but rather
> to pay attention to the result codes from the
> ast_bridge_call, to which I added the 
> AST_PBX_NO_HANGUP_PEER_PARKED value, which
> now are returned when a channel is parked.
> 
> If you get AST_PBX_KEEPALIVE,
> then don't touch the channel pointer.
> 
> If you get AST_PBX_NO_HANGUP_PEER, or
> AST_PBX_NO_HANGUP_PEER_PARKED, then don't
> touch the peer pointer.
> 
> Updated the several places where the results
> from a bridge were not being properly obeyed,
> and fixed some code I had introduced so that
> the results of the bridge were not overridden 
> (in trunk).
> 
> All the places that previously tested for 
> AST_PBX_NO_HANGUP_PEER now have to check for
> both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.

In this explanation, you say that that the peer channel pointer should 
not be touched in the case of NO_HANGUP_PEER and NO_HANGUP_PEER_PARKED. 
  However, in your code (at least in res_features), you are still 
accessing the channel in the case of NO_HANGUP_PEER.  You must not touch 
the channel in this case.

Also, why do you need the new return code for parked?  The only places 
that I see handling different from the existing NO_HANGUP_PEER code are 
where the peer channel is being accessed (when it shouldn't be).

If for CDR purposes, you _must_ be able to get data off of a channel, 
then code must be changed so that these return codes aren't used at all. 
  When code returns this result, it means that another thread has 
assumed ownership of a channel, and you absolutely must not touch it 
under any circumstance.  Otherwise, it's still going to be subject to 
random crashes.

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.



More information about the asterisk-dev mailing list