[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: rump_sys_rename & tmpfs ... memory leak ?
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.
Main Index |
Thread Index |