Valgrind found two leaks triggered by oo.test and ooNext.test. Stack traces are:

mig@X13:~/DEVEL/tcl-core/trunk/unix$ cat ERR.leaks 
Leak #1
  0:  malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  1:  TclpAlloc (tclAlloc.c:699)
  2:  Tcl_Alloc (tclCkalloc.c:1059)
  3:  AllocClass (tclOO.c:1539)
  4:  TclNRNewObjectInstance (tclOO.c:1790)
  5:  TclOO_Class_Create (tclOOBasic.c:198)
  6:  TclOOInvokeContext (tclOOCall.c:309)
  7:  TclOOObjectCmdCore (tclOO.c:2635)
  8:  PublicNRObjectCmd (tclOO.c:2451)
  9:  Dispatch (tclBasic.c:4353)
-- oo.test: ==26247== 832 (528 direct, 304 indirect) bytes in 2 blocks are definitely lost in loss record 3 of 4

Leak #2
  0:  malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  1:  TclpAlloc (tclAlloc.c:699)
  2:  Tcl_Alloc (tclCkalloc.c:1059)
  3:  AllocObject (tclOO.c:568)
  4:  TclNRNewObjectInstance (tclOO.c:1773)
  5:  TclOO_Class_Create (tclOOBasic.c:198)
  6:  TclOOInvokeContext (tclOOCall.c:309)
  7:  TclOOObjectCmdCore (tclOO.c:2635)
  8:  PublicNRObjectCmd (tclOO.c:2451)
  9:  Dispatch (tclBasic.c:4353)
-- ooNext2.test: ==26246== 832 (304 direct, 528 indirect) bytes in 2 blocks are definitely lost in loss record 2 of 2
-- oo.test: ==26247== 1,248 (456 direct, 792 indirect) bytes in 3 blocks are definitely lost in loss record 4 of 4

committing patch to trunk that stops the identified leaks
in the test suite.

The deletion code is by far the trickiest place in TclOO. It's particularly compounded by the way that oo::object and oo::class cross-reference themselves and each other. I strongly recommend only doing testing with --enable-symbols=mem enabled, as that catches a much higher proportion of bad behaviour (because it scribbles over memory when it releases).

Clear that the trouble lies in the refcount dance
found in ReleaseClassContents(). These things
are always tricky.

Refcounts for several objects found on lists
are bumped near the start.  Seems that these
objects get taken odd the lists before another
pass through the lists decrementing the refcounts
is supposed to free them.

Bisecting shows that at least the oo-14.7 leak
arrives with checkin

http://core.tcl.tk/tcl/info/9a6b1363308cade8

Likely suspect: inheritance and mixins.

dgp	oo.test leaks in oo-14.[678]

dgp	ooNext2.test leaks in oo-call-1.2[01]

Use the TCLTEST_OPTIONS env variable to govern the
valgrind with tcltest package options.  Useful ones
for narrowing causes are -file -match -verbose -skip

I also advise check pre- and post- each of the bugfixes
I mentioned before.  Knowing the patch that's bad can
be as useful as knowing the test that triggers.

There is AFAIK no simple way to determine which test triggers the leak, as valgrind will (can?) only analyze the leaks on process shutdown. I guess one would have to run each test separately under valgrind.

(i.e., we are leaking classes, not normal instances.)

Those are very unspecific traces; they just tell me that the objects were allocated using oo::class create. Any chance of narrowing down which tests trigger the leaks?

Likely suspects are

http://core.tcl.tk/tcl/tktview?name=593baa032c

and

http://core.tcl.tk/tcl/tktview?name=3d96b7076e