[mpich-discuss] mpich memory leak?

[Dave Goodell]

On Jun 8, 2012, at 3:25 PM CDT, Jed Brown wrote:

> On Fri, Jun 8, 2012 at 3:11 PM, Dave Goodell <goodell at mcs.anl.gov> wrote:
> > ==29174== 15 bytes in 1 blocks are still reachable in loss record 1 of 1
> > ==29174==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
> > ==29174==    by 0x410927: ??? (in /usr/bin/mpiexec.hydra)
> > ==29174==    by 0x40205A: ??? (in /usr/bin/mpiexec.hydra)
> > ==29174==    by 0x548AC4C: (below main) (libc-start.c:226)
> 
> This stack trace indicates that there is a small leak (possibly harmless) in libc, not in any of the actual hydra (mpiexec) code.
> 
> Isn't this pointing to a static constructor?

Maybe.  There is still a malloc call though, which I don't think we're deliberately doing via any constructor code.  Perhaps GCC is inserting this for us under the hood, but I'm not entirely convinced of this.

I'm still skeptical of this being a modern version of MPICH2 b/c of the SIGSTOP issue.

> FWIW, I get the following, though it's almost certainly harmless.
> 
> ==17609== 131,120 bytes in 2 blocks are still reachable in loss record 1 of 1
> ==17609==    at 0x4C2B8A4: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==17609==    by 0x41FC41: HYDU_sock_forward_stdio (in /home/jed/usr/mpich-gcc/bin/mpiexec.hydra)

This is probably the static local variable "fwd_hash" being allocated and never freed by hydra.  As you point out, it's mostly harmless, other than slightly cluttering the valgrind output.

-Dave