Lazarus
Programming => General => Topic started by: ArminLinder on January 27, 2022, 01:21:01 pm
-
Seens I missed to properly destroy something somewhere. In debug mode, at the end of my program, I get a list of addresses and a hint that my program has eaten some bytes (see Screenshot).
I read the docs here https://wiki.freepascal.org/leakview (https://wiki.freepascal.org/leakview) and here https://wiki.freepascal.org/heaptrc (https://wiki.freepascal.org/heaptrc) but found no information how these numbers need to be interpreted, and what they point to. I see a call to "Execute", which belongs to a TTask and is fairly long, and calls numerous subroutines. I already suspected that one of those may contain the bug, but at first glance everything seems to be fine, everything what is created is freed properly. Getting somewhat closer to where the problem is would be greatly appreciated.
And more infos available how I am supposed to use this table? Can I find out which type the offending object has been, or where it was created?
Thnx, Armin.
-
I see a call to "Execute", which belongs to a TTask and is fairly long, and calls numerous subroutines. I already suspected that one of those may contain the bug, but at first glance everything seems to be fine, everything what is created is freed properly.
Thnx, Armin.
Take a second glance.
heaptrc gives you the starting point (caller) where the issue originated from.
you can be 99.99999% sure that there is an unfreed object (or pointer) somewhere there
When i start writing a program, usually i use an additional log-file, which gets written to in each constructor and destructor of every class i use
(e.g. log-entry might look like: "2022-01-27 13:31:06: Unit MyUnit1: Line 161 - TMyClass created" (or free'ed))
If heaptrc throws me a memory-leak i just have to check the logfile and count the "create"'s against the "free"'s
-
I searched for hours now, found no problem. I suspect, the problem might be somewhere else, it is a multitasking app ...
- What do the lines with no line numbers mean?
- the block address ... is this any way related to variable addresses which I can see when inspecting code with the debugger?
I need any hint what is in that block ...
Armin.
-
It is likely that those are just stale pointers. My guess is "use after free".
-
I see a lot of BAADFOOD……
-
Maybe https://forum.lazarus.freepascal.org/index.php/topic,57840.msg430465.html#msg430465 (last section of that post)
From the image, only top 4 frame are in your app. And some may be in packages... If they are in packages, make sure they are compiled with debug info. And the same debug info for all of them, as well as the same that is used for the project itself. (ideally everything DWARF)
-
Windows
The 16 8 bytes (heaptrc.pp tracesize := 16) addresses are the return (call ?) addresses of the calling code in 32bit cpu mode when compiled in a reasonably standard way (O1).
The addresses starting with $FF are likely to be addresses in the operating system (in windows 64 they start with $7FF...).
BAADF00D are 32 bit filler initialized, probably by windows or the OS, and indicate that the slots where not used.
What are the instructions of at line 1661 of fileobserverunit.pas ?
-
https://en.wikipedia.org/wiki/Magic_number_(programming)
BAADF00D
"Bad food", Used by Microsoft's debug HeapAlloc() to mark uninitialized allocated heap memory[23]
-
Maybe https://forum.lazarus.freepascal.org/index.php/topic,57840.msg430465.html#msg430465 (last section of that post)
From the image, only top 4 frame are in your app. And some may be in packages... If they are in packages, make sure they are compiled with debug info. And the same debug info for all of them, as well as the same that is used for the project itself. (ideally everything DWARF)
Didn't help.
There is an old omission that catches up with me again: how to integrate a debuggable version of the FCL into a Lazarus project with tolerable effort, so that the FCL is automatically recompiled when switching between "debug" and "release" configuration?
I found so far only a vague instruction (https://wiki.lazarus.freepascal.org/Lazarus_FAQ#How_can_I_debug_FCL_components_from_packages_with_Lazarus) how to do this for Linux, I use Windows.
Armin.
-
There is an old omission that catches up with me again: how to integrate a debuggable version of the FCL into a Lazarus project with tolerable effort, so that the FCL is automatically recompiled when switching between "debug" and "release" configuration?
Don't automatically recompile the FCL, that is only asking for trouble sooner or later.
In general you can do this:
- build the same FPC version as your release once from source with OPT=-glw2 RELEASE=1 and do a make install to some separate location
- copy the units/<cpu>-<os> folder from the new installation to your main installation as units/<cpu>-<os>-debug
- (remove the new installation)
- edit the fpc.cfg and where the units/$fpctarget is mentioned encase that with the following
#ifdef DEBUG_FCL
<paths to $fpctarget-debug>
#else
<paths to $fpctarget>
#endif
- when you need to debug into the FCL define DEBUG_FCL in your project options and compile (might lead to recompilation of the LCL however despite that not being necessary)
Note: I have not tested this, but from my general understanding of both the compiler and Lazarus it should work this way.[/list]