Any comments on what this means or a pointer to a tutorial which might help advance my understanding of how to debug a test sequence that seems to keep growing in memory.?
This is 9.18.4 (I’ll upgrade if necessary). What’s unique about this sequence is it has nested parameter sweeps and parallel threads. I’ve looked through my source for a memory leak but can’t find any…
Hi @craig.petku,
I can reproduce this and have added a new issue.
I think this warrants a 9.19.4 release of OpenTAP, but until then you should be able to remove {Parameters} from your Sweep steps name and that should fix the issue as well.
Thank you. I confirmed deleting the {Parameters} from the step name significantly reduced memory useage although the stack for the application continues to grow (at a slower rate). The objects which are accumulating still appear to be related to the sweep step, but the overall runtime for this stress test should be greatly increased by your recommendation.
Maybe you could try this build? 904 ParameterizeStep Memory Leak by rmadsen-ks · Pull Request #905 · opentap/opentap · GitHub
It should fix the issue, but if there is other issues, it would be nice to understand it.
I assume I need to compile this. Just to verify, is there a pre-built package?
You should be able to install the package from here:
https://github.com/opentap/opentap/suites/9088931453/artifacts/421107288
Thank you,
I built it anyway since it was a quick resync with the server. this fixes the issue I was having and now memory growth is mainly the console log at a much more acceptable rate. Screen shot included to document the issue was resolved.
OK, thanks for verifying it! This will help towards getting it into a release quicker.
