[test-results] [Bamboo] Asterisk Testing > Asterisk Trunk > #1364 has FAILED. Change made by 6 authors.

[Bamboo]

-----------------------------------------------------------------------
Asterisk Testing > Asterisk Trunk > #1364 failed.
-----------------------------------------------------------------------
Code has been updated by Mark Michelson, Matthew Jordan, jrose, alecdavis, igorg, dlee.
1/2 jobs failed, with 0 failing tests.

http://bamboo.asterisk.org/browse/TESTING-ASTERISKTRUNK-1364/


--------------
Failing Jobs
--------------
  - Asterisk CentOS 6 32-Bit (CentOS 6): No tests found.



--------------
Code Changes
--------------
jrose (391430):

>bridge_native_rtp: Fix possible segfaults on leaves/joins
>
>native_rtp_bridge_get can return any result from the ast_rtp_glue_result
>enumerator and the join/leave functions for bridge_native_rtp seem to assume
>that if the result wasn't local that it was remote. Meanwhile forbid can be
>returned by that function which can mean certain glue pointers are NULL. Then
>when the join/leave functions try to use members of that pointer, boom.
>Segfault.
>

jrose (391453):

>bridge_native_rtp: Fix native bridge tech being incompatible when it should be.
>
>When checking compatability for the native RTP bridge technology there is a
>race condition between clearing framehooks that are destroyed when leaving
>certain bridges with certain technologies (such as bridge_native_rtp) and
>joining bridges with the bridge_native_rtp technology. Yes, that means a
>channel in a native RTP bridge could move to another native RTP bridge and
>be considered incompatible with the new native RTP bridge causing it to
>revert to a simple bridge technology0. This fixes that bug by ignoring
>framehooks that have been marked for destruction when checking for
>compatibility with the bridge_native_rtp technology.
>

Matthew Jordan (391479):

>Fix memory leaks in stasis_channels and bridge_native_rtp
>
>This patch fixes two memory leaks:
> * A memory leak in packing channels into a multi-channel blob payload when
>   publishing dial messages. The multi-channel blob payload does not steal
>   the references - this approach was chosen because it works well with the
>   RAII_VAR macro. Unfortunately, this does mean that you actually have to use
>   the RAII_VAR macro (or manually deref it yourself)
> * RTP instances returned as a result of one of the glue operations are ref
>   counted and have to be de-ref'd appropriately. We now do that, as saying
>   that we should do it and then not would be silly.
>
>
>



--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20130613/9f1f7881/attachment.htm>