Memory content overview. Is there a tool?

[Bluegraf]

It happened again - I buried hours into a search for a memory leak somewhere in TestStand.

This time a rogue loop never left MainSequence and caused Locals.ResultList to grow unlimited (not leaving Main was not so obvious in my setup as it may sound - but that's not the point I'm after here).

Until I looked at exactly the right place I had no idea what was eating up my memory. All the profiler tools I know of just gave me the information that something in the TS-memory grows out of control but there was nothing that helped me to narrow down my search. Actually - the first indication that something was wrong was an ever growing number of handles in the Windows Taskmanager, nothing inside TestStand.

I'm missing a way to get information about:

- all variables (within current threads/executions/engine) and their size

- all Queues, Notifications, Semaphores

I'm aware that there are security considerations involved but I could imagine that data to appear in Execution Profiler.

This could be an entry in Idea Exchange but maybe something is already something else out there. (?)

[AndreasGareis]

Hello Bluegraf,

there is no tool to my knowledge. Technically, you also did not observe a memory leak but the memory increase was due to the result collection phase of an execution.

Regardless, I'd like to point you to this troubleshooting document which touches all aspects of TestStand that influence memory and should help you in the future narrow down unexpected memory increases.

Troubleshooting Memory Growth Issues in TestStand Systems

[Bluegraf]

Hi Andreas,

thanks for the reply!

> Technically, you also did not observe a memory leak but

I totally agree. "Leak" was just the hypothesis I started my search with.

> Troubleshooting Memory Growth Issues in TestStand Systems

Great guide!

I didn't know this exact document (but some of the linked ones). Nevertheless, I followed the strategies laid out in it.

But that is exactly my point:

Basically, the documents say "If you see memory growth then do static code analysis. First focus on x, then y, then z. Additionally, disable different parts of your code, run it and check whether the issue disappears." This will sooner or later guide you to the goal but...

It is a little bit like following the path of shards in a china store instead of cranking up the air conditioning, blow the dust out and see that huge grey animal.

A size-sorted list of property names would have saved me hours: "Oh, (MainSequence.)Locals.ResultList is an array with a zillion indices - I think I should have a closer look there."

I'm missing the equivalent to the air conditioning - a tool that lets me investigate the memory a bit better than by inspecting every single property and hoping that you really know all of them.