[test-results] [Bamboo] Asterisk - Trunk > Ubuntu Lucid (10.04) > #1007 has FAILED (1 tests failed). Change made by Russell Bryant.
Bamboo
bamboo at asterisk.org
Tue Sep 20 16:35:13 CDT 2011
-----------------------------------------------------------------------
Asterisk - Trunk > Ubuntu Lucid (10.04) > #1007 failed.
-----------------------------------------------------------------------
Code has been updated by Russell Bryant.
1/175 tests failed.
http://bamboo.asterisk.org/browse/ASTTRUNK-LUCID-1007/
--------------
Failing Jobs
--------------
- amd64 (Default Stage): 1 of 175 tests failed.
--------------
Code Changes
--------------
Russell Bryant (336879):
>Merged revisions 336878 via svnmerge from
>https://origsvn.digium.com/svn/asterisk/branches/10
>
>................
> r336878 | russell | 2011-09-19 20:03:55 -0500 (Mon, 19 Sep 2011) | 43 lines
>
> Merged revisions 336877 via svnmerge from
> https://origsvn.digium.com/svn/asterisk/branches/1.8
>
> ........
> r336877 | russell | 2011-09-19 19:56:20 -0500 (Mon, 19 Sep 2011) | 36 lines
>
> Fix crashes in ast_rtcp_write().
>
> This patch addresses crashes related to RTCP handling. The backtraces just
> show a crash in ast_rtcp_write() where it appears that the RTP instance is no
> longer valid. There is a race condition with scheduled RTCP transmissions and
> the destruction of the RTP instance. This patch utilizes the fact that
> ast_rtp_instance is a reference counted object and ensures that it will not get
> destroyed while a reference is still around due to scheduled RTCP
> transmissions.
>
> RTCP transmissions are scheduled and executed from the chan_sip scheduler
> context. This scheduler context is processed in the SIP monitor thread. The
> destruction of an RTP instance occurs when the associated sip_pvt gets
> destroyed (which happens when the sip_pvt reference count reaches 0). However,
> the SIP monitor thread is not the only thread that can cause a sip_pvt to get
> destroyed. The sip_hangup function, executed from a channel thread, also
> decrements the reference count on a sip_pvt and could cause it to get
> destroyed.
>
> While this is being changed anyway, the patch also removes calling
> ast_sched_del() from within the RTCP scheduler callback. It's not helpful.
> Simply returning 0 prevents the callback from being rescheduled.
>
> (closes issue ASTERISK-18570)
>
> Related issues that look like they are the same problem:
>
> (issue ASTERISK-17560)
> (issue ASTERISK-15406)
> (issue ASTERISK-15257)
> (issue ASTERISK-13334)
> (issue ASTERISK-9977)
> (issue ASTERISK-9716)
>
> Review: https://reviewboard.asterisk.org/r/1444/
> ........
>................
>
--------------
Tests
--------------
New Test Failures (1)
- AsteriskTestSuite: S/channels/ s i p/sip channel params
--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20110920/3227579f/attachment-0001.htm>
More information about the Test-results
mailing list