[test-results] [Bamboo] Asterisk - 1.8 > Ubuntu Lucid (10.04) > #188 was SUCCESSFUL (with 194 tests). Change made by Russell Bryant.

[Bamboo]

-----------------------------------------------------------------------
Asterisk - 1.8 > Ubuntu Lucid (10.04) > #188 was successful.
-----------------------------------------------------------------------
Code has been updated by Russell Bryant.
All 2 jobs passed with 194 tests in total.

http://bamboo.asterisk.org/browse/AST18-LUCID-188/


--------------
Code Changes
--------------
Russell Bryant (303549):

>Merged revisions 303548 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>
>................
>  r303548 | russell | 2011-01-24 14:49:53 -0600 (Mon, 24 Jan 2011) | 38 lines
>  
>  Merged revisions 303546 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.4
>  
>  ........
>    r303546 | russell | 2011-01-24 14:32:21 -0600 (Mon, 24 Jan 2011) | 31 lines
>    
>    Fix channel redirect out of MeetMe() and other issues with channel softhangup.
>    
>    Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped
>    working properly.  This issue includes a patch that resolves the issue by
>    removing a call to ast_check_hangup() from app_meetme.c.  I left that in my
>    patch, as it doesn't need to be there.  However, the rest of the patch fixes
>    this problem with or without the change to app_meetme.
>    
>    The key difference between what happens before and after this patch is the
>    effect of the END_OF_Q control frame.  After END_OF_Q is hit in ast_read(),
>    ast_read() will return NULL.  With the ast_check_hangup() removed, app_meetme
>    sees this which causes it to exit as intended.  Checking ast_check_hangup()
>    caused app_meetme to exit earlier in the process, and the target of the
>    redirect saw the condition where ast_read() returned NULL.
>    
>    Removing ast_check_hangup() works around the issue in app_meetme, but doesn't
>    solve the issue if another application did the same thing.  There are also
>    other edge cases where if an application finishes at the same time that a
>    redirect happens, the target of the redirect will think that the channel hung
>    up.  So, I made some changes in pbx.c to resolve it at a deeper level.  There
>    are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to
>    abort the hangup process.  My patch extends this to remove the END_OF_Q frame
>    from the channel's read queue, making the "abort hangup" more complete.  This
>    same technique was used in every place where a softhangup flag was cleared.
>    
>    (closes issue #18585)
>    Reported by: oej
>    Tested by: oej, wedhorn, russell
>    
>    Review: https://reviewboard.asterisk.org/r/1082/
>  ........
>................
>


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