register all allocas as expected memory leaks - #30
Conversation
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
commented
Dec 15, 2016
Hi Primoz, Thanks for the contribution. Just two issues I have picked up (please correct me if I am wrong):
Best regards, |
gabr42
commented
Dec 16, 2016
via email
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ž |
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
commented
Dec 16, 2016
via email
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
commented
Dec 16, 2016
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. |
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.