shawn857
asked on
Memory leak that is driving me nuts...
Hi Experts, I have my app fitted with FastMM4 to show me the memory leaks... and I've got one that's really stumping me. Basically I enter a procedure where I declare one local instance of a variable of type TCSVBasicRecord. Let's call this instance "NewItem". TCSVBasicRecord is previously declared globally in my app as such:
(the Function CreateFromFileText does a bunch of string manipulations and basically parses a string according to CSV convention... that's not the problem)
OK, in my procedure I've got a TRY...EXCEPT block within a While loop that does the bulk of the work. When data is clean and everything works good and no exceptions are thrown, everything gets freed and tidied up nicely and no memory leaks are reported when I exit my app. But when I run a test with erroneous data that triggers an exception and enters the EXCEPT block, I get a stupid memory leak. In my EXCEPT block, I show an error message and then terminate the app, but just before doing so, I make sure to perform the exact same free-ing of objects and closing of files that I do when the app runs successfully. So I'm just baffled by this... any thought anyone please?
Thanks
Shawn
type TCSVBasicRecord = class(TObject)
public
Fields: TStringList; // de-quoted
OriginalTexts: TStringList; // including quotes/double quotes
Constructor Create;
Destructor Destroy; override;
Class Function CreateFromFileText(var AllText: string; delimiter_: char; quoteChar_: char; endOfRecordIndicator: string): TCSVBasicRecord;
end;
(the Function CreateFromFileText does a bunch of string manipulations and basically parses a string according to CSV convention... that's not the problem)
OK, in my procedure I've got a TRY...EXCEPT block within a While loop that does the bulk of the work. When data is clean and everything works good and no exceptions are thrown, everything gets freed and tidied up nicely and no memory leaks are reported when I exit my app. But when I run a test with erroneous data that triggers an exception and enters the EXCEPT block, I get a stupid memory leak. In my EXCEPT block, I show an error message and then terminate the app, but just before doing so, I make sure to perform the exact same free-ing of objects and closing of files that I do when the app runs successfully. So I'm just baffled by this... any thought anyone please?
Thanks
Shawn
I probably can't help with this but I know the experts who can will need to see the problem code to ensure you are freeing everything correctly.
mlmcc
mlmcc
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Merjin - no leak when I close my app normally - only when I purposely enter my exception code and I terminate it.
I'm going to make a stripped-down version of my app and attempt to replicate the error so it will be more clear that way. Then I'll post the full code. I'll be back in a bit!
Thanks
Shawn
I'm going to make a stripped-down version of my app and attempt to replicate the error so it will be more clear that way. Then I'll post the full code. I'll be back in a bit!
Thanks
Shawn
ASKER
Well, as I was stripping it down, I found the problem boys - some other objects that I was failing to clean up during the terminate, that I would normally clean up during the normal program exit. Duhhh, sorry guys! I'm going to split the points amongst the 3 of you - Marco, Merjin and Geert. Thanks and sorry for the bother!
Shawn
Shawn
ASKER
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):
5 - 12 bytes: TCSVBasicRecord x 17, AnsiString x 40
13 - 20 bytes: TObjectList x 1, TList x 2
37 - 44 bytes: TSystemInfo x 1
45 - 52 bytes: TStringList x 34
53 - 60 bytes: AnsiString x 238
101 - 108 bytes: Unknown x 34
173 - 188 bytes: Unknown x 1
Note: To obtain a log file containing detail on memory leaks, enable the "FullDebugMode" and "LogMemoryLeakDetailToFile
----------
That "TCSVBasicRecord x 17" is the culprit - all the other leaks reported are due to that one. I don't know how it would tally up 17 occurrences of TCSVBasicRecord leaking - I only declared one instance of it ("newItem") in my procedure... and I made sure I planted my erroneous data in the very first record the WHILE loop read. It's really got me scratching my head, for sure.
Thanks!
Shawn