[asterisk-dev] [Code Review] 2434: Prevent crash when externally initiated DTMF is begun/ended on a SIP channel that has just finished processing a BYE

[Joshua Colp]

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

Ship it!


Ship It!

- Joshua Colp


On April 9, 2013, 5:35 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2434/
> -----------------------------------------------------------
> 
> (Updated April 9, 2013, 5:35 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-20225
>     https://issues.asterisk.org/jira/browse/ASTERISK-20225
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> A race condition can occur between a channel that has a DTMF played back on it from AMI and the underlying SIP dialog receiving a BYE request. The DTMF will be queued up for action on the channel and - while the frames are queued up - a BYE request will be received. The SIP pvt will be removed from the channel and the tech_pvt pointer set to NULL. When the channel lock is released, the frames get processed. This will call either sip_senddigit_begin/sip_senddigit_end and - since the pvt is NULL - the dreaded FRACK error will occur.
> 
> (Or you just crash)
> 
> This patch does the really simple thing and bails if the pvt pointer is NULL. It's actually valid - there isn't any way for AMI to know that the pvt just got nuked, and chan_sip is locking the channel while it removes the pvt. Sometimes, you just have to check that something isn't NULL before you use it.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 384779 
> 
> Diff: https://reviewboard.asterisk.org/r/2434/diff/
> 
> 
> Testing
> -------
> 
> A test I was writing stops crashing. Yay!
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130409/f0d05af1/attachment-0001.htm>