[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

[Matt Jordan]

-----------------------------------------------------------
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.


Changes
-------

Return res instead of being explicit with 0.


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 (updated)
-----

  /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/953a624a/attachment.htm>