Am 30.07.2018 um 02:58 schrieb Ben Grasset:
Call trace for block $7CDCDD60 size 416
$0001DA72
$0001BF6A
$000100217BB0 TCGCALLPARANODE__CREATE, line 146 of ncgcal.pas
$000100138E6D TINLINENODE__HANDLE_READ_WRITE, line 1364 of ninl.pas
$00010013F731
Am 30.07.2018 um 02:58 schrieb Ben Grasset:
Call trace for block $5E642220 size 56
$0001DB6B
$0001000A35ED TNODE__ALLOCOPTINFO, line 973 of node.pas
$000100164889 SETEXECUTIONWEIGHT, line 366 of optutils.pas
$0001000C2873 FOREACHNODESTATIC, line 321 of nu
I'm somewhat surprised to see all the mentions of try-finally in
response to this.
The issues I found and described here are all clearly just simple cases
of variables being created and then never freed. Part of what likely
leads to this is that the compiler relies in many places on checking
Am 30.07.2018 um 02:58 schrieb Ben Grasset:
This raises a couple of big questions:
Considering that FPC provides optional built-in memory tracking that will take you directly to the exact source line
number of a leak, the fact that there's so many either means people have simply not been doing
On Sun, 29 Jul 2018, Ben Grasset wrote:
I was feeling inquisitive today, so I added
'SetHeapTraceOutput('log.trc');" to the first line of pp.pas and built
myself a debug copy of the compiler using Lazarus. After building the
following very simple program:
I tried other, more complex things a
I was feeling inquisitive today, so I added
'SetHeapTraceOutput('log.trc');" to the first line of pp.pas and built
myself a debug copy of the compiler using Lazarus. After building the
following very simple program:
program Test2;
{$mode objfpc}{$H+}
procedure TestProc(const S: String);
begin
