Has anyone an idea why FastMM's FullDebugMode takes hours to end an application?
Has anyone an idea why FastMM's FullDebugMode takes hours to end an application?
I'm working in a huge project. After spending a lot of time I've managed to get the application run in FullDebugMode. When I close the application immedtiately after the start I get a detailed memory leak report file including stack traces. But when I work with the application (performing REST requests, parsing huge JSON strings, creating and destroying many objects etc.) the FullDebugMode takes at least several hours before the application will terminate. Has anyone seen this happen before? Is there a way to solve it?
I'm working in a huge project. After spending a lot of time I've managed to get the application run in FullDebugMode. When I close the application immedtiately after the start I get a detailed memory leak report file including stack traces. But when I work with the application (performing REST requests, parsing huge JSON strings, creating and destroying many objects etc.) the FullDebugMode takes at least several hours before the application will terminate. Has anyone seen this happen before? Is there a way to solve it?
Could it be live leak, massive one?
ReplyDeleteThank you all, I've found the problem in the depths of very old Turbo Pascal code. There was a strange self made object collection that stores pointer addresses as integers and attempts to cast them back to objects later. In FullDebugMode the (very strange) clear method got into an infinit loop. Replacing the Turbo Pascal code with a generic TObjectList fixed the problem.
ReplyDelete