[asterisk-bugs] [JIRA] (ASTERISK-28826) memory leak in res_rtp_asterisk.c
Joshua C. Colp (JIRA)
noreply at issues.asterisk.org
Tue Apr 14 06:57:25 CDT 2020
[ https://issues.asterisk.org/jira/browse/ASTERISK-28826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joshua C. Colp updated ASTERISK-28826:
--------------------------------------
Assignee: nappsoft
Status: Waiting for Feedback (was: Triage)
The code uses ast_data_buffer_get before the mentioned code is executed to see if the sequence number is already in the receive buffer, and if so doesn't proceed and outputs a log message. This handles the case where the same packet is received multiple times. Things are locked such that it should not be possible for the buffer to have been modified while this is happening. Can you explain further how the scenario you've mentioned is occurring?
As well on sending the NACK retransmission of RTP packets does not use the same path as normal sending, so they aren't added to the send buffer again.
> memory leak in res_rtp_asterisk.c
> ---------------------------------
>
> Key: ASTERISK-28826
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-28826
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_rtp_asterisk
> Affects Versions: 16.9.0
> Reporter: nappsoft
> Assignee: nappsoft
> Labels: patch, webrtc
> Attachments: patch1.diff
>
>
> When a packet is received twice (and though ast_data_buffer_put would report "Packet with position ... is already in buffer. Not inserting.") the payload will never be freed resulting in a memory leak.
> This behavior could be observerd with asterisk 16.9 during WebRTC conferences when some clients had bad connections and some packets needed to be repeated.
> Attached you'll find a patch that fixes the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list