MadExcept StartLeakChecking is causing random access violations

[aehimself]

This is a crosspost from Delphi Praxis.

Hello,

We have a large Delphi application with MadExcept purchased and integrated already. When I put the line "StartLeakChecking;" in this project, random nullpointer access violations start to happen... for example at TSpeedButtom.Glyph.Assign, because TSpeedButton.Glyph is nil. Errors do not appear without StartLeakChecking, with ReportMemoryLeaksOnShutdown := True or when debugging via DeLeaker.

As noone reported any similar findings in the original topic I decided to bring the question here. Please keep in mind that the nullpointer exception is being raised within VCL, because - for a strange reason - some inner properties are not created (properly? Going to wrong address spaces?). The issue disappears if StartLeakChecking does not exist in the project.

I'm looking for any hints or pointers as at the moment I have no idea what is happening

Thanks!

[madshi]

Hmmmm... It's been a while since I looked into leak reporting. But I don't think it's intended that you have leak reporting disabled in your madExcept project settings and then you calling StartLeakChecking. Does the problem go away if you enable leak reporting globally in the madExcept project settings?

[aehimself]

The reason I'm using StartLeakChecking is because I can not find where to enable it. My MadExcept configuration window looks like this:

madexcept.PNG (5.71 KiB) Viewed 211 times

This link says that there should be a "MadExcept settings" in the project popup menu which is missing for me; therefore I have no idea where to find this window.

Using Delphi 10.4.1 and MadExcept 5.10.

[madshi]

There should be a "madExcept Settings..." menu item in your "Project" menu. Is it not there?

[aehimself]

Ah, I was looking at the wrong place; I thought it should be in the right-click menu on the project.

Issue is the same if I enable error reporting from the project options. Can this be turned off for different build configurations? On for Debug, off for Release?

Something is wrong when leak checking is enabled in MadExcept; I see some signs of memory corruption... but only when leak checking is enabled.
I'll try to look into this...

[madshi]

The intended way to use leak reporting is to enable it in the madExcept settings. See "report resource leaks" option here:

http://help.madshi.net/madExceptSettings1.htm

Have you done that? It's not recommend that you disable leak reporting in the madExcept settings, and then manually call StartLeakChecking. That cannot work very well because leak reporting requires replacing the memory manager, and if your project starts running without leak checking and then you turn it on manually later, there were already many allocations done by the original memory manager. Then turning leak reporting on will replace the memory manager, but the new one will not know how to handle allocations done by the original one.

It's recommended that you have madExcept active for both debug and release builds. Arguably, the main purpose of madExcept is to help you catch crashes which happen on end user PCs. So it's even more useful to enable madExcept for release builds than for debug builds.

However, leak reporting is something that is mainly intended for your development PC. I would not recommend doing leak reporting on end user PCs. You don't have to disable leak reporting for end users, though. There's a neat little trick here: Leak reporting requires the "madExcept32/64.dll" to be present. On your development PC, madExcept will automatically find and use the DLL. But if you don't distribute this DLL with your application, end users will not have the madExcept32/64.dll, so leak reporting will automatically be turned off for them (without any negative side effects).

[aehimself]

Have you done that?

Yes, I removed the StartLeakChecking and enabled leak checking in the dialog.

It's not recommend that you disable leak reporting in the madExcept settings, and then manually call StartLeakChecking. That cannot work very well because leak reporting requires replacing the memory manager, and if your project starts running without leak checking and then you turn it on manually later, there were already many allocations done by the original memory manager. Then turning leak reporting on will replace the memory manager, but the new one will not know how to handle allocations done by the original one.

Good to know, thank you for letting me know!

There's a neat little trick here: Leak reporting requires the "madExcept32/64.dll" to be present. On your development PC, madExcept will automatically find and use the DLL. But if you don't distribute this DLL with your application, end users will not have the madExcept32/64.dll, so leak reporting will automatically be turned off for them (without any negative side effects).

That's wonderful Will definetly use this solution if I can get leak checking to work.

I am still getting strange issues - probably memory corruptions when leak checking is enabled, mostly during DFM streaming. Components are getting corrupted, some objects simply become "nil", some are littered with chinese characters in the object inspector. The strange thing is everyting works fine with FastMM (you mentioned enabling this feature replaces the memory manager).
I can not enable crashing on buffer overflow, as the program will run out of memory during startup.

Is there a way to find out what is going wrong when MadExcept's memory manager is active?

[madshi]

I'd suggest to start with a simple test project and see if you can reproduce the problem there. If not, maybe you can build a simply hybrid of the test project and your real project to figure out where the problem is coming from? FWIW, so far nobody else has reported this problem. Which, of course, doesn't mean that it can't be a bug in madExcept.

[aehimself]

Do you have access to the DevExpress components? There is a really simple test component based on a DevExpress control where the issue appears on an empty VCL project.

[madshi]

No, I don't have them.

[aehimself]

I'll check with DevExpress support tomorrow. Maybe they can try with MadExcept trial if they don't have it purchased.

I'll report back what they can find.

[madshi]

Could this be UPX related? Does this also happen without UPX?

[aehimself]

No; not the real application nor the empty VCL application was compressed. Just compiled and executed.