[asterisk-dev] [Code Review] 4166: testsuite: tests/bridge/bridge_action leaves a channel open

[Corey Farrell]

> On Nov. 13, 2014, 11:30 a.m., Mark Michelson wrote:
> > With the fix being made to the leaked bridge in Asterisk, is this change still required? Does hanging up self.channels[1] not result in self.channels[3] and the bridge being destroyed as expected?
> 
> Corey Farrell wrote:
>     Still required, I'm guessing that when the first channel hangs up it leaves the second in a single user bridge.  I'm not sure if this is a bug in Asterisk or just the way it works.  The XMLDOC doesn't specify.

Actually on further inspection it appears the bridge is destroyed, and the caller is sent back to the previous Dialplan location.  core show channels without hangup of self.channels[3]:
Channel              Location             State   Application(Data)             
Local/waiting_area at d (None)               Up      Echo()                        
Local/waiting_area at d (None)               Up      Echo()                        
2 active channels
2 active calls
14 calls processed

If I then run 'channel request hangup Local/waiting_area at default-00000003;1' (or hangup ;2), the test finishes and passes leak free.

This is strange to me, why all the other channel pairs were hung up but not this one.


- Corey


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4166/#review13745
-----------------------------------------------------------


On Nov. 11, 2014, 3:37 p.m., Corey Farrell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4166/
> -----------------------------------------------------------
> 
> (Updated Nov. 11, 2014, 3:37 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> -------
> 
> self.channels[3] is not hung up, causing the Asterisk graceful shutdown to timeout.  This causes the test to fail under REF_DEBUG mode and prevents coverage from seeing the code executed by this test.
> 
> 
> Diffs
> -----
> 
>   /asterisk/trunk/tests/bridge/bridge_action/bridge_action.py 5920 
> 
> Diff: https://reviewboard.asterisk.org/r/4166/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141113/35d1f494/attachment-0001.html>