[asterisk-dev] [Code Review] MALLOC_HOLD for debugging memory

[Russell Bryant]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/309/#review1000
-----------------------------------------------------------



/branches/1.4/main/astmm.c
<https://reviewboard.asterisk.org/r/309/#comment2362>

    The comment appears to be slightly mis-placed, as this is what is unlinking it from the non-free list.



/branches/1.4/main/astmm.c
<https://reviewboard.asterisk.org/r/309/#comment2363>

    Very nice, simple solution.



/branches/1.4/main/astmm.c
<https://reviewboard.asterisk.org/r/309/#comment2364>

    
    
    Here are some more thoughts on this code ...
    
    If some freed memory is written to, this will detect it.  However, the detection of it occurring may not happen for 2 minutes.  In most of the cases where I have used valgrind to determine the cause of an obscure crash, it was due to memory corruption that happened _right_ before the crash occurred.  Additionally, many of the crashes have to do with invalid reads, where the memory has been recycled and legitimately changed since it was freed.
    
    So, with that said, the fact that it may detect some problems is a good thing.  However, I question what percentage of the cases we would want valgrind for that this will help with by pro-actively reporting problems.
    
    In the case of an invalid read, though, it may be obvious that it is due to reading from a freed object, as its contents will be zeroed out while we hold it around.  If that is the case, and we could get to the memory region object relatively easy (without having to manually go through the list of freed regions, ugh), then we could find out where the object was originally allocated.  Additionally, in this circumstance, it would be extremely useful to also know where it got freed.  
    
    I suppose given the address of the freed object, you can calculate the beginning of the ast_region and get the data that way.
    
    Through my thinking in text form, I come to the following suggestions:
    
    1) Store the information about where the free() occurred.
    
    2) Write some documentation, in doxygen somewhere preferably, which describes how MALLOC_HOLD works, in what cases it may held, as well as some tips on what you can do in gdb to get some hints after a crash due to invalid reads on a freed object with this enabled.


- Russell


On 2009-07-15 13:11:20, Tilghman Lesher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/309/
> -----------------------------------------------------------
> 
> (Updated 2009-07-15 13:11:20)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> MALLOC_HOLD is an optional compile-time definition used to detect memory corruption.  It does this in a similar way to valgrind, although it does not slow down Asterisk appreciably (although the memory will grow somewhat larger than normal).
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/build_tools/cflags.xml 205150 
>   /branches/1.4/main/astmm.c 205150 
> 
> Diff: https://reviewboard.asterisk.org/r/309/diff
> 
> 
> Testing
> -------
> 
> Extensive testing with an idle system.  (While this sounds like an oxymoron, because this is dealing with memory management, there are a ton of memory requests merely during startup routines.  Also, idle for me means 'not heavy load' but did include testing with several active IAX2 calls.)
> 
> 
> Thanks,
> 
> Tilghman
> 
>