]> git.ipfire.org Git - thirdparty/asterisk.git/commit
res/res_rtp_asterisk: Fix assignment after ao2 decrement 02/1402/1
authorMatt Jordan <mjordan@digium.com>
Wed, 7 Oct 2015 01:43:58 +0000 (20:43 -0500)
committerMatt Jordan <mjordan@digium.com>
Wed, 7 Oct 2015 01:51:28 +0000 (20:51 -0500)
commita78beb6d4dc4de79eb2d18c021f18e2c4993c1e9
tree068efd0f30586e270bccc6eec3c531e644fcf0c3
parent6851c42eeb198d1452a768331bc7fa7ce8d0962c
res/res_rtp_asterisk: Fix assignment after ao2 decrement

When we decide we will no longer schedule an RTCP write, we remove the
reference to the RTP instance, then assign -1 to the stored scheduler ID
in case something else comes along and wants to see if anything is scheduled.

That scheduler ID is on the RTP instance. After 60a9172d7ef2 was merged to
fix the regression introduced by 3cf0f29310, this improper assignment on a
potentially destroyed object started getting tripped on the build agents.

Frankly, this should have been crashing a lot more often earlier. I can only
assume that the timing was changed just enough by both changes to start
actually hitting this problem.

As it is, simply moving the assignment prior to the ao2 deference is sufficient
to keep the RTP instance from being referenced when it is very, truly,
aboslutely dead.

(Note that it is still good practice to assign -1 to the scheduler ID when we
know we won't be scheduling it again, as the ao2 deref *may* not always destroy
the ao2 object.)

ASTERISK-25449

Change-Id: Ie6d3cb4adc7b1a6c078b1c38c19fc84cf787cda7
res/res_rtp_asterisk.c