Re: rump_sys_rename & tmpfs ... memory leak ?

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Tue Apr 28 2009 at 17:12:53 +0200, Nicolas Joly wrote:
> > ==22185== 880 bytes in 220 blocks are definitely lost in loss record 5 of 7
> > ==22185==    at 0x61285EA: calloc (vg_replace_malloc.c:279)
> > ==22185==    by 0x66FEF55: rumpuser_mutex_init (in 
> > /usr/lib/librumpuser.so.0)
> > ==22185==    by 0x6454040: rumpns_mutex_init (locks.c:90)
> > ==22185==    by 0x645346E: rumpns_uao_create (vm.c:231)
> > ==22185==    by 0x6167C5E: rumpns_tmpfs_alloc_node (tmpfs_subr.c:173)
> > ==22185==    by 0x61685FE: rumpns_tmpfs_alloc_file (tmpfs_subr.c:475)
> > ==22185==    by 0x616473C: rumpns_tmpfs_create (tmpfs_vnops.c:266)
> > ==22185==    by 0x642E4DB: rumpns_VOP_CREATE (vnode_if.c:178)
> > ==22185==    by 0x6205C6E: rumpns_vn_open (vfs_vnops.c:178)
> > ==22185==    by 0x62098C5: rumpns_sys_open (vfs_syscalls.c:1327)
> > 
> > mmm, valgrind
> 
> On NetBSD ?

Yes.  I've been using vg4nbsd (http://vg4nbsd.berlios.de/) occasionally
for debugging kernel memory leaks.  Since rump uses so few system calls,
you can generally get a sensible result.  But you need to completely
disable threading.  This means 1) using rumpuser_pth_dummy.c in
librump/rumpuser/Makefile 2) not linking librumpuser to libpthread
3) running with env RUMP_THREADS=0.

In the general case you'll probably have better luck compiling rump
on Linux and running valgrind there.  disclaimer: I haven't done it in
a while.  Perhaps I should try, support might have bitrotted again.