I have a requirement to implement a "SESSION:FIRST-CALL" (+ :NEXT-SIBLING) like others "SESSION:First-*" (query, buffer, procedure, data-source, ....).
I Would need to find a way to track "Create call" to investigate a memory leak in a 4GL application.
The additional tracing described in the article http://knowledgebase.progress.com/articles/Article/P133306 is too heavy to be used in a production environment.
The article "http://knowledgebase.progress.com/articles/Article/P124514" "How to check for leaked dynamic objects" does not describe a way to detect the CALL objects not being cleaned .
Do you really use that many CALL objects that you need something like this to track all of their usage in order to determine if they're causing a memory leak?
You could simply search your code for all usages of CALL objects and make sure that there is adequate cleanup code or add them to a WIDGET-POOL to ensure they're cleaned up.
Alternatively you should be able to reproduce any ABL memory leak outside of your production environment by simply running the same code you're running in production.
Just because a memory leak hasn't snowballed up to the point where it's tipping over your application in your dev/qa environment doesn't mean it won't be just as detectable by using DynObjects.* logging.
IMHO all code should be tested with DynObjects.* logging as part of routine QA before releasing. That said, in 99.9% of the cases, as long as you test the various aspects of your application you DON'T have to test in production to find your own memory leaks.
Hi Ken,
We have a tool that can do this (we did a breakout session about it at the EMEA PUG at Noordwijk "Mind your Performances ! Use a Quality Check Tool")
In this tool we can see all the dynObjects which are not cleaned, we are using it daily on all our new sources.
Our mistake is :
- we developp this tool last year .
- We have more than 6 "old" versions of our ERP (with more than 6 000 source code "standart" on each one) and several thousand of specific source code dedicated for specific client.
We cannot control all our old source code, too much time to do this.
For example , our last memory leak (more than 1 Gb) was an old version , only due to "CREATE CALL" which was not cleaned up.
We have some "Break point" somewhere in all our source code where we can ask the session to do something like "Extract all the dynobject " => we are blind on the CALL objects.
If i know that we have 10 more CALL objects between point A and point B , it will be easy for me to find where the developper must clean up them.
Regards
Patrice