[asterisk-dev] [Code Review] Lock the peer->mwipvt to avoid crashed in sip history management when overflowing history entries

[irroot]

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

Ship it!


It will be best to be consistant and lock the peer on entering sip_send_mwi_to_peer and unlock when we leave remove the locks around where it is called in various places this will prevent any problems.

Thx

- irroot


On Aug. 18, 2011, 7:15 a.m., Olle E Johansson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1373/
> -----------------------------------------------------------
> 
> (Updated Aug. 18, 2011, 7:15 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Historically, mwi was sent by one thread (monitor) and did not need any locking. With the addition of event driven MWI, we now have two threads, the event thread and the monitor thread for retransmits, that work on the same pvt. We have had multiple crashes in 1.6.0 caused by fights over the sip history linked list and memory corruption when removing entries (when the list overflows). Looking at it, we realized that no locking was done so the two threads where allowed to have fun with the same pvt at the same time.
> 
> This affects everything since the historic day we released 1.6.0
> 
> 
> This addresses bug asterisk-18288.
>     https://issues.asterisk.org/jira/browse/asterisk-18288
> 
> 
> Diffs
> -----
> 
>   ./trunk/channels/chan_sip.c 332444 
> 
> Diff: https://reviewboard.asterisk.org/r/1373/diff
> 
> 
> Testing
> -------
> 
> Compiled fine. Felt fine. Under testing now.
> 
> 
> Thanks,
> 
> Olle E
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110905/4651dcba/attachment.htm>