I'm using mpich2-1.1a2 built with debug (passing --enable-g=all to mpich2's configure).
When running snes/examples/tutorials/ex19 with 2 processors, I get the following lines in the output: In direct memory block for handle type ATTRIBUTE KEY, 6 handles are still allocated In direct memory block for handle type COMM, 3 handles are still allocated In indirect memory block 0 for handle type COMM, 3 handles are still allocated [1] 24 at [0x084a4fb0], mpid_vc.c[63] [1] 8 at [0x08301438], local_proc.c[364] ..... [1] 16 at [0x0837b7f8], mpid_vc.c[63] In direct memory block for handle type ATTRIBUTE KEY, 6 handles are still allocated In indirect memory block 0 for handle type COMM, 8 handles are still allocated [0] 16 at [0x09be9670], mpid_vc.c[63] .... [0] 8 at [0x09aec918], local_proc.c[363] [0] 16 at [0x099ff400], mpid_vc.c[63] The ATTRIBUTE KEY leaks are expected, PETSc does not frees all created keyvals. But the others, those related to "COMM", are unexpected. Moreover, the full petsc4py testsuite does not show those warnings, not ex19 with 1 proc or ex5f with 1 proc (both also run by 'make test'). So I suspect that DMMG code (or the ex19 code) is leaking communicators. If someone of you have a bit of time, please look at this. -- Lisandro Dalc?n --------------- Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC) Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC) Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET) PTLC - G?emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
