Re: Possible bug in Tcl.pm exposed by Tktable?

On 3/7/2020 10:01 PM, Christopher Chavez wrote:
> =3D=3D17734=3D=3D=C2=A0 Address 0x52012a0 is 8,400 bytes inside a block =
of size
> 16,384 alloc'd
> =3D=3D17734=3D=3D=C2=A0=C2=A0=C2=A0 at 0x483577F: malloc (vg_replace_mal=
loc.c:299)
> =3D=3D17734=3D=3D=C2=A0=C2=A0=C2=A0 by 0x5550DFE: GetBlocks (tclThreadAl=
loc.c:1044)
> =3D=3D17734=3D=3D=C2=A0=C2=A0=C2=A0 by 0x5550549: TclpAlloc (tclThreadAl=
loc.c:358)
=E2=80=A6
> =3D=3D17734=3D=3D=C2=A0 Address 0x536add0 is 8,720 bytes inside a block =
of size
> 16,384 alloc'd
> =3D=3D17734=3D=3D=C2=A0=C2=A0=C2=A0 at 0x483577F: malloc (vg_replace_mal=
loc.c:299)
> =3D=3D17734=3D=3D=C2=A0=C2=A0=C2=A0 by 0x5550DFE: GetBlocks (tclThreadAl=
loc.c:1044)
> =3D=3D17734=3D=3D=C2=A0=C2=A0=C2=A0 by 0x5550549: TclpAlloc (tclThreadAl=
loc.c:358)
> =3D=3D17734=3D=3D=C2=A0=C2=A0=C2=A0 by 0x5471A87: Tcl_Alloc (tclCkalloc.=
c:1059)


The addresses involved are inside allocations from Tcl's thread block
cache, which I'm guessing could be heavily reused over the life of a Tcl
program (to minimize direct calls to malloc()). I'll ask Tcl developers,
but is anyone here aware of a way to disable this or make it
debugging-friendly to identify what the last user of the block is?