Tcl Source Code

==5593== 152 bytes in 1 blocks are definitely lost in loss record 4 of 6
==5593==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==5593==    by 0x5D14E2: TclpAlloc (tclAlloc.c:699)
==5593==    by 0x43D1AE: Tcl_Alloc (tclCkalloc.c:1059)
==5593==    by 0x5A6E23: AllocObject (tclOO.c:565)
==5593==    by 0x5A9262: TclNRNewObjectInstance (tclOO.c:1724)
==5593==    by 0x5AC12D: TclOO_Class_Create (tclOOBasic.c:198)
==5593==    by 0x5AEB90: TclOOInvokeContext (tclOOCall.c:303)
==5593==    by 0x5AB364: TclOOObjectCmdCore (tclOO.c:2584)

Repaired and recommitted to the trunk.

It's possible the repair technique has broader application.

Pushed the checkin off the trunk, because the test suite
was crashing terribly with it.

Looking deeper now it appears that the trouble arises
when slave interps are deleted.

That was indeed the origin, and it was a subtle problem with the interlock mechanism that stopped weird delete race conditions between an instance going because of its name getting deleted and because of its class going. Evil.

One-line fix plus test.

Revised apparent leak origin:

checkout:     3e85aec4f2cb620504f3ea120e9ca28c532d560e 2012-03-26 12:51:15 UTC

Yeah, I suspect it may be a different leak.

That's quite a large commit, none of which is related to TclOO. Any hope of identifying what's really going on?

(The test itself is checking that a global command name doesn't cause problems with a local object name during create, but I can't see how that commit could have anything to do with that test as it doesn't use unset at all. All variable deletion is done by destruction of the namespace.)

This leak appears to be introduced by checkin

211541cc9ec23f38b93e7343a5cfefa2b9412cf7 2010-01-30 16:33:25 UTC