Finding Memory Leak fast with Spring4D container?

[egroups 0]

Hi there,

I convert legacy application to using Spring4D container for dependency injection.

For memory leaks using FastMM4.

Occasionally appear memory leak in different places and I solve them gradually.

The problem is with the use of dependency injections, FatsMM generates very large log file (aka 2GB) and very long time.Some registered class in container not call Destroy (memory leaks in dependency graph).

Is there any way to more easily and quickly detect places where there is a memory leak?

Any extension for container or different method?

[Brian Evans 83]

A code analyzer might be able to catch errors like that. Not sure if Pascal Analyzer (Peganza - PAL) would catch them in code using Spring4D dependency injection but they might add it if asked. 

[Stefan Glienke 1905]

The usual reasons for memory leaks that I have seen:

- not using interfaces as service types

- registered components are not inheriting from TInterfacedObject (or some other properly reference counting implementing class)

- in combination with the previous point when using AsSingleton without explicitly stating a value for TRefCounting to tell the container if the class implements ref counting or not

- injected dependencies are further passed to and held by other services creating cross or cyclic references (use LeakCheck to better find them than just looking through the huge list that FastMM produces, ideally in a smaller scope, 2GB memleak log sounds a bit huge)

 

You can log some of that information by iterating .Registry.FindAll from the container instance and checking various properties of each TComponentModel such as ComponentType, Services and LifetimeType.

[egroups 0]

On 2/28/2024 at 4:49 PM, Stefan Glienke said:

The usual reasons for memory leaks that I have seen:

- not using interfaces as service types

- registered components are not inheriting from TInterfacedObject (or some other properly reference counting implementing class)

- in combination with the previous point when using AsSingleton without explicitly stating a value for TRefCounting to tell the container if the class implements ref counting or not

- injected dependencies are further passed to and held by other services creating cross or cyclic references (use LeakCheck to better find them than just looking through the huge list that FastMM produces, ideally in a smaller scope, 2GB memleak log sounds a bit huge)

 

You can log some of that information by iterating .Registry.FindAll from the container instance and checking various properties of each TComponentModel such as ComponentType, Services and LifetimeType.

Thanks Stefan,I try LeakCheck and Registry.FindAll