[asterisk-bugs] [JIRA] (ASTERISK-27229) Crash due to duplicate free in ast_bridge_update_talker_src_video_mode

Kevin Harwell (JIRA) noreply at issues.asterisk.org
Wed Sep 6 17:37:09 CDT 2017


    [ https://issues.asterisk.org/jira/browse/ASTERISK-27229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=238540#comment-238540 ] 

Kevin Harwell commented on ASTERISK-27229:
------------------------------------------

Asterisk should not be crashing that is for sure. When it does it is always helpful to have a backtrace(s) on the issue (See [Getting a Backtrace|https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace] for more info).

I haven't looked closely, but your thoughts about where it is crashing sound like that possibly could be the case.

Also, since you have already looked at the code and have an idea on a fix, here is more info ([Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]) on how to do that if you are interested :-)

> Crash due to duplicate free in ast_bridge_update_talker_src_video_mode
> ----------------------------------------------------------------------
>
>                 Key: ASTERISK-27229
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27229
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Bridging
>    Affects Versions: 14.6.0
>         Environment: CentOS 7
>            Reporter: Richard Kenner
>
> I've had two Asterisk crashes today that seem to be caused by errors
> where chan->tech_pvt is pointing to something that can't be deallocated
> and I think I see a reference count bug in the above function.
> It contains:
> {noformat}
>                 if (data->chan_old_vsrc) {
>                         ast_channel_unref(data->chan_old_vsrc);
>                 }
> {noformat}
> Shouldn't this also have:
> {noformat}
>                         data->chan_old_vsrc = NULL;
> {noformat}
> It seems to me that if it doesn't and the next condition also isn't
> true, then the next time this same code is executed, it'll decrement
> the reference count of the old channel again, which is wrong since it
> hasn't been decremented.



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list