Thanks, Mattias and Joost,
now I understand the real bug is in my assumptions on what goes on
behind the screens. But that leads to another question: is there any
documentation where I can read up on this so that I may improve on my
programming, and particular debugging, skills?
wolf
On 16/06/17 23:27, Mattias Gaertner via Lazarus wrote:
On Fri, 16 Jun 2017 21:43:38 +1200
Wolf via Lazarus <lazarus@lists.lazarus-ide.org> wrote:
If I understand you correctly, because
1. command line parameters are internally treated as a null-terminated
string (i.e. AnsiString), a call to ParamStr() implies a heap allocation
and thus,
2. since ParamStr() is handled by the system unit, a call to halt will
result in a memory leak because Heaptrc is not aware of this allocation.
No, that's not how temporary strings work.
Just move the code in front of your halt into a separate procedure and
the mem leaks are gone.
The compiler creates an implicit try..finally to free managed types
and since Halt skips the finally parts the strings are not freed.
If this is correct, then the conclusion has to be that Heaptrc cannot be
trusted as a debugging tool because it is ill-informed about what the
system unit is up to.
Nonsense. This is neither specific to the system unit nor heaptrc.
The conclusion is that must not use Halt, when you need try..finally.
Mattias
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus
