[asterisk-bugs] [JIRA] (ASTERISK-27238) Bridging: Crash freeing a frame that's already been freed

Richard Kenner (JIRA) noreply at issues.asterisk.org
Sun Oct 1 09:14:08 CDT 2017


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

Richard Kenner edited comment on ASTERISK-27238 at 10/1/17 9:12 AM:
--------------------------------------------------------------------

I wanted to provide an update.  I'm using valgrind as my test here, rather than looking at crashes.  I removed the patches above, as well as two patches I had tried to use to fix this issue.  When I do that, I still see the valgrind errors, though now they're a bit harder to reproduce and appear to need both somebody coming into conference bridge using sln16 and ulaw (so there's a conversion from 8k to 16k).

What I found is that if I protect the "ast_frfree (middle_frame)" around line 955 in audiohook.c with
{noformat}
  if (middle_frame != start_frame)
{noformat}

the problem goes away.  That seems like quite a safe patch because the routine should never be returning a frame that it just freed, but it's a mystery to me why others aren't seeing this bug or whether this is actually the proper fix.




was (Author: kenner):
I wanted to provide an update.  I'm using valgrind as my test here, rather than looking at crashes.  I removed the patches above, as well as two patches I had tried to use to fix this issue.  When I do that, I still see the valgrind errors, though now they're a bit harder to reproduce and appear to need both somebody coming into conference bridge using sln16 and ulaw (so there's a conversion from 8k to 16k).

What I found is that if I protect the ast_frfree (middle_frame) around line 955 in audiohook.c with
{noformat}
  if (middle_frame != start_frame)
{noformat}

the problem goes away.  That seems like quite a safe patch because the routine should never be returning a frame that it just freed, but it's a mystery to me why others aren't seeing this bug or whether this is actually the proper fix.



> Bridging: Crash freeing a frame that's already been freed
> ---------------------------------------------------------
>
>                 Key: ASTERISK-27238
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27238
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Bridging
>    Affects Versions: 14.6.0
>         Environment: Centos 7
>            Reporter: Richard Kenner
>            Assignee: Unassigned
>         Attachments: confbridge.conf, traceback.txt, valgrind.txt
>
>
> See traceback.txt traceback.  The frame being freed is below:
> {noformat}
> $2 = {frametype = AST_FRAME_VOICE, subclass = {integer = 0, 
>     format = 0x24bc940, frame_ending = 0}, datalen = 0, samples = 320, 
>   mallocd = 1, mallocd_hdr_len = 545, offset = 64, 
>   src = 0x7f554c00c7a8 "func_jitterbuffer interpolation", data = {ptr = 0x0, 
>     uint32 = 0, pad = "\000\000\000\000\000\000\000"}, delivery = {
>     tv_sec = 1504146592, tv_usec = 647484}, frame_list = {
>     next = 0x7f5544002de0}, flags = 0, ts = 0, len = 0, seqno = 0}
> {noformat}



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



More information about the asterisk-bugs mailing list