showing code lines

[maqtech]

Hi chap team,
how can I enable showing the infected code lines ?
is it possible ?

[timboddy]

Hi maqtech,

I'm not sure that I fully understand your question but a guess might be that, given a reported memory leak, you would like to understand the stack trace. In general, chap doesn't support that because it does not instrument the binary or source code in any way and so does not save stack trace information at the time of each allocation. I have considered enhancing chap to take advantage of cores generated from code instrumented by some other tool but haven't gotten around to that.

Do I understand your use case correctly?

[maqtech]

exactly @timboddy , thanks for the information, I'd like to use chap, but I need a full report of the memory issues I have within my code.

[timboddy]

If stack traces are important to you, what are your reservations about using some tool such as valgrind that actually does the instrumentation needed to be able to supply stack traces?

[maqtech]

this is the question I'm trying to answer but in another manner, why another tool if there is already a well-established tools to do the same task ? what are the pros and the cons of the chap, this is why I gave it a try and I asked the question.

[timboddy]

There are several answers as to why one might want to use chap even though other tools might exist. At the time I wrote it (or rather the not open source predecessor), I was actually trying to resolve a different problem, which was how, given a core dump from a crashed process that had run out of memory, I could figure out why the process had run out of memory without asking for a new core after instrumentation. It is inconvenient to reproduce crashes and such requests often annoy the person who is asked to reproduce the problem. Some problems are not easy to reproduce, and instrumentation often slows things down. So the first use case, which is still probably the most important use case for chap, is to answer questions about memory usage from un-instrumented cores. One can do this very well using chap because chap makes it easy to walk an approximation of the reference graph for chap, both forwards, in the direction of the memory reference, and backwards, from a memory location to places that reference it.

The second use case was actually memory leak analysis. The value added by chap here, given that tools already exist that show stack traces for leaked objects is that it works on un-instrumented cores. This has the advantage that one can take a core after pretty much any test, even ones for which instrumentation would be unacceptable (due to time or memory space or to wanting to run the tested product in its normal form) and check it for leaks. This is easily automated so one can add value to any test by doing an additional check to see whether the code paths executed by those tests are leaky. Once one has eliminated the leaks found by chap during these tests, if one runs these tests before a developer attempts to submit a change it is pretty easy to catch leaks before they are checked in to the code base.

A third is that chap can be used as a supplement to gdb, for cases where someone wants to understand the usage of a particular memory location. Try the "describe" command within chap on various addresses to see what I mean.

I gave a few presentations to introduce chap. The first was at ACCU 2017. The second, from C++ Now 2017, is available here:
https://www.youtube.com/watch?v=EZ2n3kGtVDkThe presentation is slightly dated in that it does not yet mention the "/extend" switch or the "describe" command, which were added after that, but it does give a reasonable introduction.