Slides:
https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-20-2017_saturday/chap_a_memory_analyzer_for_un_instrumented_cores__tim_boddy__cppnow_05-20-2017.pdfVideo:
https://www.youtube.com/watch?v=EZ2n3kGtVDkTraditionally, memory usage analysis and memory leak analysis for C and C++ programs involve instrumenting either source code or binary code before running it through a series of tests. Such an approach, depending on how aggressively the code is instrumented, can result in false leak reports, if the code is not sufficiently instrumented to completely understand whether allocations are still in use, or can distort the timing so much that it is not practical to run on a regular basis. What is worse, if the memory usage of interest happened using code that was not instrumented, it may not be practical to reproduce the problem, for example due to dependence on some obscure code path or on some test that is expensive to run. One other limitation of instrumentation is that it often changes the algorithm itself, and in doing so makes cases where the memory growth is due to allocator-specific behavior less clear to analyze.
At VMware I have developed a tool, now called CHAP but until very recently called ah64, that avoids these issues by analyzing un-instrumented core files, either live cores or cores from crashes, for leaks and memory usage and corruption. It does not report any false leaks and is sufficiently reliable that we run it in an automated way to catch leaks before they are checked in to our code base. We also use it regularly to understand memory growth issues and cases of memory corruption. In this talk I will discuss how the tool works and how to use it to address the use cases described earlier in this paragraph.
VMware has now made this available as open source at http://github.com/vmware/chap. At present it is working only for Linux ELF cores generated with programs that use glibc malloc. There was prototyped support for at least one other allocator, but that prototype cannot be made available as open source without permission from the owners of that allocator. Some expected areas of enhancement for CHAP are likely to include support for other open source allocators, such as tcmalloc and jemalloc, support for other dump formats, better scripting, and use of DWARF information to make usage analysis more precise.
