Groups | Search | Server Info | Login | Register

Groups > perl.tcltk > #532

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

Show all headers | View raw

On 3/7/2020 10:01 PM, Christopher Chavez wrote:
> ==17734==  Address 0x52012a0 is 8,400 bytes inside a block of size
> 16,384 alloc'd
> ==17734==    at 0x483577F: malloc (vg_replace_malloc.c:299)
> ==17734==    by 0x5550DFE: GetBlocks (tclThreadAlloc.c:1044)
> ==17734==    by 0x5550549: TclpAlloc (tclThreadAlloc.c:358)
…
> ==17734==  Address 0x536add0 is 8,720 bytes inside a block of size
> 16,384 alloc'd
> ==17734==    at 0x483577F: malloc (vg_replace_malloc.c:299)
> ==17734==    by 0x5550DFE: GetBlocks (tclThreadAlloc.c:1044)
> ==17734==    by 0x5550549: TclpAlloc (tclThreadAlloc.c:358)
> ==17734==    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?

Back to perl.tcltk | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Possible bug in Tcl.pm exposed by Tktable? chrischavez@gmx.us (Christopher Chavez) - 2020-03-07 22:01 -0600
  Re: Possible bug in Tcl.pm exposed by Tktable? chrischavez@gmx.us (Christopher Chavez) - 2020-03-16 03:48 -0500
    Re: Possible bug in Tcl.pm exposed by Tktable? chrischavez@gmx.us (Christopher Chavez) - 2020-03-16 04:09 -0500
      Re: Possible bug in Tcl.pm exposed by Tktable? chrischavez@gmx.us (Christopher Chavez) - 2020-03-16 04:22 -0500
      Re: Possible bug in Tcl.pm exposed by Tktable? chrischavez@gmx.us (Christopher Chavez) - 2020-03-16 22:08 -0500

csiph-web