Link to home
Start Free TrialLog in
Avatar of shawn857
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:

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;

Open in new window


(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
Avatar of shawn857
shawn857

ASKER

Oh, by the way - here is the FastMM4 memory leak report that gets output:

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" conditional defines. To disable this memory leak check, undefine "EnableMemoryLeakReporting".
----------

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
Avatar of Mike McCracken
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
SOLUTION
Avatar of Marco Gasi
Marco Gasi
Flag of Spain image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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
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