[test-results] [Bamboo] Asterisk - Team Branches > Pimp My SIP > #403 has FAILED. Change made by root.

Bamboo bamboo at asterisk.org
Thu Jun 13 21:19:10 CDT 2013


-----------------------------------------------------------------------
Asterisk - Team Branches > Pimp My SIP > #403 failed.
-----------------------------------------------------------------------
Code has been updated by root.
1/2 jobs failed, with 0 failing tests.

http://bamboo.asterisk.org/browse/ASTTEAM-PIMPMYSIP-403/


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



--------------
Code Changes
--------------
root (391564):

>Fix segfault for certain invalid WebSocket input.
>
>The WebSocket code would allocate, on the stack, a string large enough
>to hold a key provided by the client, and the WEBSOCKET_GUID. If the key
>is NULL, this causes a segfault. If the key is too large, it could
>overflow the stack.
>
>This patch checks the key for NULL and checks the length of the key to
>avoid stack smashing nastiness.
>
>(closes issue ASTERISK-21825)
>Reported by: Alfred Farrugia
>Tested by: Alfred Farrugia, David M. Lee
>Patches:
>    issueA21825_check_if_key_is_sent.patch uploaded by Walter Doekes (license 5674)
>........
>
>Merged revisions 391560 from http://svn.asterisk.org/svn/asterisk/branches/11
>........
>
>Merged revisions 391561 from file:///srv/subversion/repos/asterisk/trunk
>

root (391679):

>Multiple revisions 391675-391676
>
>........
>  r391675 | mjordan | 2013-06-13 13:14:38 -0500 (Thu, 13 Jun 2013) | 8 lines
>  
>  Blow away usage of libjansson's foreach macro
>  
>  While very handy, this macro didn't occur until a later version of libjansson.
>  We'd prefer to be compatible with older versions still - as such, iteration
>  over key/value pairs in a JSON object have to be done with a little bit more
>  manual work.
>........
>  r391676 | mmichelson | 2013-06-13 13:17:13 -0500 (Thu, 13 Jun 2013) | 10 lines
>  
>  Fix memory leak in features_config.c
>  
>  The options should not be registered multiple times. Instead, the configuration just needs
>  to be reprocessed by the config framework. This also exposed that we were not properly telling
>  the config framework to treat the configuration processing with the "reload" semantics when
>  a reload occurred. Both of these errors are fixed now.
>  
>  Thanks to Richard Mudgett for discovering the leak.
>........
>
>Merged revisions 391675-391676 from file:///srv/subversion/repos/asterisk/trunk
>

root (391649):

>Refactor CEL bridge events on top of Stasis-Core
>
>This pulls bridge-related CEL event triggers out of the code in which
>they were residing and pulls them into cel.c where they are now
>triggered by changes in bridge snapshots. To get access to the
>Stasis-Core parking topic in cel.c, the Stasis-Core portions of parking
>init have been pulled into core Asterisk init.
>
>This also adds a new CEL event (AST_CEL_BRIDGE_TO_CONF) that indicates
>a two-party bridge has transitioned to a multi-party conference. The
>reverse cannot occur in CEL terms even though it may occur in actuality
>and two party bridges which receive a AST_CEL_BRIDGE_TO_CONF will be
>treated as multi-party conferences for the duration of the bridge.
>
>Review: https://reviewboard.asterisk.org/r/2563/
>(closes issue ASTERISK-21564)
>........
>
>Merged revisions 391643 from file:///srv/subversion/repos/asterisk/trunk
>



--
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/13186a87/attachment-0001.htm>


More information about the Test-results mailing list