[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
Paul Belanger
reviewboard at asterisk.org
Tue Apr 9 12:31:55 CDT 2013
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2434/#review8211
-----------------------------------------------------------
/branches/1.8/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/2434/#comment15841>
return res? Since we already have it
/branches/1.8/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/2434/#comment15842>
same comment
- Paul Belanger
On April 9, 2013, 5:14 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:14 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/fc154f22/attachment.htm>
More information about the asterisk-dev
mailing list