What are good strategies for debugging memory leaks in a transformation plugin?

[Carlos Guerreiro <ca...@gmail.com>]

Hi,

I suspect a transformation plugin I'm writing is leaking memory.
What are good strategies for debugging memory leaks in an transformation
plugin?

How to determine if all data structures created by a plugin are released by
the time the continuation is destroyed? Is there any existing support for
this?
How to distinguish increasing RAM use for caching from leaks?

When enabling memory dumps (
https://github.com/apache/trafficserver/blob/master/doc/sdk/troubleshooting-tips/debugging-memory-leaks.en.rst)
what do the allocated and in_use counts mean exactly?

Best regards,
Carlos

Re: What are good strategies for debugging memory leaks in a transformation plugin?

[James Peach <jp...@apache.org>]

On Nov 28, 2013, at 6:58 AM, Carlos Guerreiro <ca...@gmail.com> wrote:

> Hi,
> 
> I suspect a transformation plugin I'm writing is leaking memory.
> What are good strategies for debugging memory leaks in an transformation
> plugin?

This can be somewhat interesting due to the use of freelists, as discussed below. I have not found particularly good leak debugging tools on Linux, but I would be thrilled to be educated if there are some good ones around.

If you are debugging this in a test environment, then I'd recommend building Traffic Server with the --disable-freelist configuration option. Then you can use tools like valgrind (Linux) or leaks (Mac OS X) to test for leaks. My preference is often leaks, since it is much less trouble.

> How to determine if all data structures created by a plugin are released by
> the time the continuation is destroyed? Is there any existing support for
> this?
> How to distinguish increasing RAM use for caching from leaks?
> 
> When enabling memory dumps (
> https://github.com/apache/trafficserver/blob/master/doc/sdk/troubleshooting-tips/debugging-memory-leaks.en.rst)
> what do the allocated and in_use counts mean exactly?

This memory dump is showing you the freelist. In general, ATS keeps per-thread lists of commonly used objects and never releases these back to the malloc subsystem. Allocated and in use tells you how many objects are allocated on the list and how many are currently in use.

Memory debugging is not as good as it should be. I'd be happy to hear any suggestions you might have, or any changes we can make to make it easier

J