[asterisk-bugs] [JIRA] (ASTERISK-27238) Yet another crash freeing a frame that's already been freed

[Richard Kenner (JIRA)]

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

Richard Kenner edited comment on ASTERISK-27238 at 9/5/17 6:25 PM:
-------------------------------------------------------------------

I tested it to the extent of running valgrind and seeing  all the errors go away.  I would think that a leak of this size would show up really quickly in increasing process memory usage and I didn't see that: it stayed rock solid.  I didn't realize that MALLOC_DEBUG would be useful here compared to valgrind, but I can certainly do that and see if it shows anything. 

Unfortunately, I don't think that setting up an environment for me to be able to use git/Gerrit for a one-character patch is worthwhile.

Moreover, I quite understand that the code here is extremely complex and that I don't have the fundamental knowledge of Asterisk frame and memory management needed to know if this seems correct or if there's something else wrong.  It would seem to me to be odd that a bug of this severity would have been seen before.  In addition, the code here is the same in 14.3 and that doesn't doesn't exhibit this issue for me.  So I'm more than a bit skeptical that this is the correct fix, but view my suggesting it as more a way to focus somebody who *does* understand this stuff to a possible place to look.


was (Author: kenner):
I tested it to the extent of running valgrind and seeing  all the errors go away.  I would think that a leak of this size would show up really quickly in increasing process memory usage and I didn'[t see that: it stayed rock solid.  I didn't realize that MALLOC_DEBUG would be useful here compared to valgrind, but I can certainly do that and see if it shows anything. 

Unfortunately, I don't think that setting up an environment for me to be able to use git/Gerrit for a one-character patch is worthwhile.

Moreover, I quite understand that the code here is extremely complex and that I don't have the fundamental knowledge of Asterisk frame and memory management needed to know if this seems correct or if there's something else wrong.  It would seem to me to be odd that a bug of this severity would have been seen before.  In addition, the code here is the same in 14.3 and that doesn't doesn't exhibit this issue for me.  So I'm more than a bit skeptical that this is the correct fix, but view my suggesting it as more a way to focus somebody who *does* understand this stuff to a possible place to look.

> Yet another 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: 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)