Heaptrc shows a line that does not exist lazarus / 62-General ---------------------------------------------------------------------- simone · 2018-10-15 16:20 Dear all, I have a strange problem with Heaptrc, that shows a line that does not exist (i.e. the line number is greater than the number of lines in my unit) How is it possible? is there a possible explanation? Thanks in advance. ---------------------------------------------------------------------- Thaddy · 2018-10-16 07:05 If the program is linked against libraries that do not contain line info. (like the rtl and provided packages) If you are sure you do not use external - meaning non-native pascal - libraries, you can build the rtl and packages with lineinfo. ---------------------------------------------------------------------- Martin_fr · 2018-10-16 10:12 Seems strange... You don't by any change use external debug info, and have an old outdated debug info file (*.dbg) around? You should also have the address? then you can try and use gdb, to map the address to line info. Maybe that gets a better result? ---------------------------------------------------------------------- simone · 2018-10-16 13:37 Thanks to all. I don't use external library.  I'm working on Windows with Lazarus 1.8.4+FPC 3.0.4. The problem arises with Lazarus for 64bits. Using the same version for 32 bits the heap trace is correct and thus I have been able to find the leak. ---------------------------------------------------------------------- Thaddy · 2018-10-16 14:19 That is strange. Can you share what it was? ---------------------------------------------------------------------- simone · 2018-10-16 14:53 The problem arises in a personal medium-sized project. I will try ro reproduce it in a smaller piece of code. For now I can show the trace, although I think it is useless for a diagnosis (see attached heap.trc). (UGraphData.pas unit has n. 545 lines. In the trace appear lines n. 959, 997). I'm really grateful for the support. ---------------------------------------------------------------------- Martin_fr · 2018-10-16 17:29 Well load the app in question in gdb Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i gdb yourapp.exethen Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i info line *0x012345678with whatever address is on the bad line. You can also try to use dwarf vs stabs as symbol info type (project options / debugging // but also for each package) There are various things that can be wrong. - the actual line info written by fpc to your app - the line info reader that fpc adds to your app (unit lineinfo (stabs) or  lnfodwrf (dwarf)) there are tools like objdump that may be able to decompile the line info, if you want to go that way. For a bug report, it would be real important to know where the error is. (And also if released/older fpc has the problem too) ---------------------------------------------------------------------- simone · 2018-10-16 17:34 Dear all, I have been able to isolate the problem of heap trace in a smaller piece of code. (see attached zip). In the file heap.trc the line 959 of UGraphData.pas does not exist. PS: The attached code has no meaning. It is the result of successive eliminations starting from the original one, for the sole purpose of reproducing the problem. I hope this can be useful. ---------------------------------------------------------------------- Akira1364 · 2018-10-19 04:49 Something's up with your FPC installation, I think. Building your program with native-64-bit trunk FPC on Windows 10 gives me this: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i 78 memory blocks allocated : 3372/358477 memory blocks freed     : 3324/35361 unfreed memory blocks : 48True heap size : 229376 (160 used in System startup)True free heap : 228960Should be : 228976Call trace for block $0000000000101390 size 48  $000000010000B972  $00000001000090AA  $0000000100031C5D  CREATE,  line 1009 of fgl.pp  $0000000100031D95  CREATE,  line 27 of Ugenerator.pas  $0000000100001B61  COMPILE,  line 82 of MyGraphCompiler.lpr  $00000001000018C1  DORUN,  line 57 of MyGraphCompiler.lpr  $0000000100030DB5  $0000000100001C19  main,  line 92 of MyGraphCompiler.lpr  $0000000100001C46  $0000000100010B60  $0000000100001740  $00007FFA3BE88102  $00007FFA3C6AC5B4 which appears to be the correct output. ---------------------------------------------------------------------- simone · 2018-10-19 06:04 Thanks Akira. The problem appears with Lazarus 1.8.4+FPC 3.0.4 32 bits on Windows 7. I will reinstall Lazarus to see what happens. ---------------------------------------------------------------------- Martin_fr · 2018-10-21 23:20 I had a quick look at it. Line 959 is actually in fgl. But because you specialize the generic in UGraphData, it is incorrectly placed in that unit. (I can reproduce with 3.0.2 and 3.0.4) I tested with trunk, and with 3.2-beta: Both of them correctly report the line in fgl. So the issue is fixed in upcoming code. Until then, check any specialized generic.