register all allocas as expected memory leaks

[gabr42]

Implemented two EnableMemoryLeakReporting-mode methods
StartRegisteringAllThreadAllocationsAsExpectedLeaks and
StopRegisteringAllThreadAllocationsAsExpectedLeaks. Windows only.

Rationale: customer calls RegisterPropertyEditor from a program (not
package) and RegisterPropertyEditor creates a memory leak which cannot
be cleaned (local TList in a system unit) and cannot be correctly
registered (Unknown and UnicodeString leaks).

Call StartRegisteringAllThreadAllocationsAsExpectedLeaks to register all
following memory allocations as expected memory leaks.

Call StopRegisteringAllThreadAllocationsAsExpectedLeaks to stop that
behaviour.

Only one thread at a time can be in that state; if a second thread tries
to enter it, it will be blocked until the first thread exits from that
state.

[pleriche]

Hi Primoz,

Thanks for the contribution. Just two issues I have picked up (please correct me if I am wrong):

1. It appears that the new Start/StopRegistering... calls are also declared outside of FullDebugMode, but they only have an effect inside FullDebugMode.
2. While inside this mode should freed memory blocks not automatically be removed from the registered leaks list? I am a bit worried about overflow, since the leaks list is limited to a couple of thousand entries.

Best regards,
Pierre

[gabr42]

Re: [pleriche/FastMM4] register all allocas as expected memory leaks (#30) Hi Primoz, Thanks for the contribution. Just two issues I have picked up (please correct me if I am wrong): It appears that the new Start/StopRegistering... calls are also declared outside of FullDebugMode, but they only have an effect inside FullDebugMode. While inside this mode should freed memory blocks not automatically be removed from the registered leaks list? I am a bit worried about overflow, since the leaks list is limited to a couple of thousand entries. Best regards, Pierre — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread. Hi Pierre, 1) They are declared in EnableMemoryLeakReporting mode. Is that not enough? I'm sometimes a bit confused with all the FastMM defines. 2) That is a good idea, I'll amend the commit. Primož

[pleriche]

FullDebugMode is separate from EnableMemoryLeakReporting: Leak reporting works outside of FullDebugMode as well, but you don't get stack traces.

Regarding the logging of all allocations as leaks, I fear that even if you deregister all blocks in FreeMem that the maximum of about 2300 entries under 32-bit (half under 64-bit) in the registered leak list will still not be enough. It really wasn't designed with this purpose in mind. The code that manages it is also not particularly fast (it performs linear searches), and without a redesign it will become slow if you increase the size of the list.

[gabr42]

Re: [pleriche/FastMM4] register all allocas as expected memory leaks (#30)

FullDebugMode is separate from EnableMemoryLeakreporting: Leak reporting works outside of FullDebugMode as well, but you don't get stack traces.

Got it. So basically I would have to move the new code from DebugGetMem to FastGetMem. Can do that.

Regarding the logging of all allocations as leaks, I fear that even if you deregister all blocks in FreeMem that the maximum of about 2300 entries under 32-bit (half under 64-bit) in the registered leak list will still not be enough. It really wasn't designed with this purpose in mind. The code that manages it is also not particularly fast (it performs linear searches), and without a redesign it will become slow if you increase the size of the list.

I'm already using this code in production so it is definitely useful :) The code was meant to wrap small sections of code that you cannot modify in other way. For example:  {$IFDEF FullDebugMode}StartRegisteringAllThreadAllocationsAsExpectedLeaks;{$ENDIF}  RegisterPropertyEditor(...);  {$IFDEF FullDebugMode}StopRegisteringAllThreadAllocationsAsExpectedLeaks;{$ENDIF} Primož

[the-Arioch]

not very related thought...

May there be a registration of memory blocks, allocated in one thread and freed in another ?

I mean, most of the objects are expected to have a thread-local lives. Owner responsibility is not transferred. But some do, and those some require special measures for access synchronization.

Just a widl idea, that maybe there is both a technical feasibility and a possible benefit to check - for most objects except for specially marked - that they did not passed threads boundary in terms of ownership.