madshi.net

Calling this:

MadExcept.ClearLeaks(False,false);
Then
MadExcept.ReportLeaksNow(False);

Would expect this to return no leaks instead we are getting "Filtering child leaks" dialog in bottom right and this takes a very very long time - never seen it complete yet.

App is quite large, tried in 32bit and get the same.

Any thoughts?

Regards
Matt

The objective is to be able to capture "running" leaks where we might be adding to a list and not freeing until shutdown for example. Normal detect memory leaks on shutdown does not capture these kinds of errors.

Does this build fix it?

http://madshi.net/madCollectionUpdate.exe

madshi wrote:Does this build fix it?

http://madshi.net/madCollectionUpdate.exe

Thankyou, will check and let you know in next day or so.

So original problem is still present still says "Filtering child leaks" even if i enter this after application.initialize (should be nothing to look at);
MadExcept.StopLeakChecking(False);

Theoretically there should be very limited new leaks when I do this:

MadExcept.ClearLeaks(False,false);
MadExcept.ReportLeaksNow(False);

After testing on a small 64bit app it seems to work ok. I get a few "leaks" from the creation of the report only. But that takes a second or two so not "instant" so im wondering if its still sorting through alot of objects or items when cleared still?

With large app - clear then report - CPU core maxes and its busy doing something - for a long time.

I have not yet seen it complete.

With leak reporting on the "big" app is only running 550MB (normaly 230MB or so without madexcept leak checking) in memory so not huge by 64bit standards. When i do a ClearLeaks(False,false) memory usage remains unchanged? would have expected it to shrink somewhat?

Any ideas from the above?

Is it the ClearLeaks or the ReportLeaksNow which takes such a long time? I suppose it's the ReportLeaksNow, correct? Is there an easy way for me to reproduce the problem? I don't have any monstrously sized Delphi projects to test this with, especially not 64bit capable ones.

ReportLeaksNow is what is taking a disproportionate amount of time.

Attached a test, this is a "tiny" app but takes 11 sec to process child leaks the first time (on an i7 8700k), then near instant the second time in same instance.

That not running in IDE either, that does not seem to change the time taken.

I think this will highlight the issue for you.

Same for 32bit and 64bit so i don't think that is the problem being 64bit only.

Run app then tap ClearAndReportLeaks button. Then tap a second time to see it much faster.

Please let me know what you see.

this is in delphi 10.2.3

Any updates on this?

Sorry, busy adding support for Delphi 10.4 right now. Will look into this soon.

Thankyou please do, would like to deploy with this test in place as we are having an issue with running memory use. These issues are hard to track with a large app.

Any chance you can bump this up your Todo list, either that or release source code so I can fix it? i really do need to use this feature. (Its why i bought mad except) But it does not work.

here we are 1 month later... can we please have this fixed urgently.

I'm so sorry for taking so long. Will try to get this done early next week.

many thanks I do need this looked at asap.

So here's a new build:

http://madshi.net/madCollectionUpdate.exe

I've double checked the code and calling "ClearLeaks()" only marks the leaks as being no leak. But they're still checked for parent/child leaks. I'm not 100% sure why I've done this, to be honest, but I suppose that I must have had a good reason and I'm scared to break something. So instead now I've added this new API to madExcept.pas:
Calling this in addition to ClearLeaks() should make things fast for you.