Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2007-02

Ansistring and General Memory Management - Questions

4 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Jason P Sage

I've read about the heap manager, I know that ansistring's behave well in multi-threaded apps - if you do your house keeping, but I'm trying to track a memory leak - and I have a question.

I appreciate any and all responses, and I'm basically looking for validation or to be corrected.

If I allocate a large number of ansistrings of random lengths, change lengths, and then set them all to empty like this: MyAnsi:='' Does the heap release all that memory or does it hang on to it to "reuse" the various "chunks" that are not in use when appropriate?

The reason I ask is I appear to have a memory leak - but it might be the heap manager "saving the memory" for use later versus reallocating the memory.

I am quite aware leaks happen - and they are usually my fault when I encounter them - but it might be I'm chasing my tail because the heap manager is doing something innovative and everything is fine, and there is not a leak.

Note: I'm aware of heap trace but the nature architecture my project just does not agree with heap trace. Certain things I do purposely it mistakes as an error and these same "constructs" run leak proof in other applications.

Thank you in Advance,
Jason P Sage

Reply by email

Jonas Maebe
to Jason P Sage
Jason P Sage wrote 6 lines
If I allocate a large number of ansistrings of random lengths, change lengths, and then set them all to empty like this: MyAnsi:='' Does the heap release all that memory or does it hang on to it to "reuse" the various "chunks" that are not in use when appropriate?

It may hang around for a while. Whether or not it does depends on many different factors, including the size of the block (blocks with similar small sizes are allocated from pools, and a pool is only released back to the OS if all blocks of a pool have been freed -- although one empty pool is always kept in order to avoid a border condition where allocating/freeing a single block causes constant allocating and freeing of a block from/to the OS).

Show quoted text 6 lines
Note: I'm aware of heap trace but the nature architecture my project just does not agree with heap trace. Certain things I do purposely it mistakes as an error and these same "constructs" run leak proof in other applications.

Things which are flagged as errors by heaptrace are not leaks, but writing past the boundaries of allocated memory blocks. This may also lead to memory leaks due to corruption of the memory manager's internal data structures.

Jonas

Reply by email

Jason P Sage

I'm still on the look out for responses to my previous post if any one is interested - but I wanted to share a blooper if this is ok. This frustrated me intensely - but the ability to laugh at myself - is a good thing! I found this rather amusing - something only a computer programmer could find humorous:

-------------------------------------------------- CODE SNIPPET---BEGIN
--------------------------------------------------

//==========================================================================
===
Destructor JFC_CGIENV.destroy;
//==========================================================================
===
Begin
  // BROKEN CODE - THIS is the memory leak Created by Jason 2007-02-13 and
  // found in the snow storm of 2007-02-14 - the following day - and fixed -
  // after half a day/ lost tracking down this dumb (censored) right here!
  {Inherited;
  self.ENVVAR:=JFC_XDL.create;
  self.DATAIN:=JFC_XDL.create;
  self.CKYIN:=JFC_XDL.create;
  self.CKYOUT:=JFC_XDL.create;
  }
  { the fix - duh? How could I do this ahhhh!!!! Jason}
  self.ENVVAR.destroy;
  self.DATAIN.destroy;
  self.CKYIN.destroy;
  self.CKYOUT.destroy;
  Inherited;
End;
//==========================================================================
===

-------------------------------------------------- CODE SNIPPET---END
--------------------------------------------------

Best Regards,

Jason P Sage

http://www.jegas.com

Reply by email