[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
reviewboard at asterisk.org
Tue Apr 9 12:14:14 CDT 2013
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2434/
-----------------------------------------------------------
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/4cfd2528/attachment.htm>
More information about the asterisk-dev
mailing list