[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