Memory leak

[user5]

I have one small (I think) memory leak in the program I'm working on but even with LeakView I'm having trouble tracing it. For testing purposes, the only thing I'm doing now to get the trace is to open and close the main form of the program without doing anything else.

    Of course I need to eventually fix the leak, but I'm wondering if I really have an urgent problem if the leak is very small. If the program only creates a one-time 31 byte block of memory that isn't returned when the program is ended then I can live with that for a while until I can get some help or learn more. I have many other things that need attention. I read all the other posts about leaks on this forum.

    Here's what I need to know: Does heap.trc get its data from all code that hasn't been run yet or does it get the info only after that code has been run? If you guys can tell me that then that's the answer that I really need. If it's the former then the leak could be anywhere but if it's the latter then the leak is in the main form. LeakView report below:

Code: Pascal  [Select][+][-]

1. Call trace for block $08D7D size 31
2.  $0041D64B  TCUSTOMFORM__DOCLOSE,  line 974 of ./include/customform.inc
3.  $004202E5  TCUSTOMFORM__CLOSE,  line 2092 of ./include/customform.inc
4.  $004204F4  TCUSTOMFORM__WMCLOSEQUERY,  line 2172 of ./include/customform.inc
5.  $0040CC16
6.  $006257EE  TWINCONTROL__WNDPROC,  line 5322 of ./include/wincontrol.inc
7.  $0041E527  TCUSTOMFORM__WNDPROC,  line 1437 of ./include/customform.inc
8.  $00681D75  DELIVERMESSAGE,  line 117 of lclmessageglue.pas
9.  $005EE13F  WINDOWPROC,  line 2426 of ./win32/win32callback.inc
10.  
11.  
12.  
13.  

[user5]

I won't take any more of anyone's time on this oddball problem other than to say that I simply took a "Halt" statement out of the main form close procedure and now the program has no memory leaks!

It seems like just coming to this forum helps me to solve my problems sometimes.

[molly]

Memory leaks are usually created by yourself.

As such, describing the problem has no use for someone trying to help you. It is like the proverbial needle in a haystack simply because there is no code to check.

In case of such issues always try to create a simple test project for us to see/tst and which shows the same issue.

In hindsight: You never should use halt unless in panic mode. (panic, meaning you have encountered a situation that is unresolvable). Before calling halt you should manually free the resource(s) that you've allocated. An alternative would be to make use of AddExitProc just after allocating a resource (the provided exitproc then freeing the allocated resource for you).

[Thaddy]

Yup. Give us some code. And also compile with -glh (do not include heaptrc unit manually!)

Also note that users like Molly or me or more, can spot memory leaks in your source code more often than not just by examining it, if it is, like you said, really simple.
That's why we need source code that reproduces it. Always.

[gregv]

Yup. Give us some code. And also compile with -glh (do not include heaptrc unit manually!)

What is the difference between -glh and use heaptrc?

[User137]

Safe way to close app is to call .Close on main form, or Application.Terminate. Both will ensure that things are freed.

[Martin_fr]

What is the difference between -glh and use heaptrc?

-glh is the same as -gl -gh

-gl is include line number info AND unit lineinfo or <forgotten name, same for dwarf>
  that is line numbers are a subset of debug info / the unit is to read them from your app and display them

-gh is heaptr / IIRC this includes -gl

so there may not be a diff.

For more see google the help an fpc.

[Thaddy]

Yup. Give us some code. And also compile with -glh (do not include heaptrc unit manually!)

What is the difference between -glh and use heaptrc?

You should NEVER EVER add heaptrc to the uses clause yourself.
That is because the unit is included by compiler magic, since the startup code in system already allocates memory and you end up having memory allocated by two different memory managers.
Normally not an issue, but it is an issue if you want to trace.

So always use -glh or -gl -gh

This includes the heaptrc unit for you and before any memory is allocated.
This is also documented, but the default documentation is wrong. (http://www.freepascal.org/docs-html/rtl/heaptrc/usage.html is wrong)

I filed a bug report against the documentation.

Of course I include -gl line numbers to have a more meaningful trace.

[Thaddy]

The docs for 3.0.2 are already corrected. See: http://bugs.freepascal.org/view.php?id=30637

[Gary Randall]

See User137's reply.  If program isn't closed properly heap.trc won't be closed and won't make sense.