|
From: Christian P. <tr...@ge...> - 2005-08-24 20:24:49
|
On Wednesday 24 August 2005 16:13, Nicholas Nethercote wrote: > On Wed, 24 Aug 2005, Christian Parpart wrote: > > I'm having the following backtrace in my server's shutdown summary of V= G: > > > > =3D=3D13271=3D=3D 16 bytes in 1 blocks are still reachable in loss reco= rd 8 of 56 > > =3D=3D13271=3D=3D at 0x1B905E1A: calloc (in > > /usr/lib/valgrind/vgpreload_memcheck.so) =3D=3D13271=3D=3D by 0x1CFC= B3A3: > > (within /lib/libdl-2.3.5.so) > > =3D=3D13271=3D=3D by 0x1CFCAD60: dlopen (in /lib/libdl-2.3.5.so) > > > > Well, I'm pretty pretty sure that I dlclose()'d every > > module and plugin I've been loading, although, this is > > somewhat far within dlopen() itself. > > > > So, might this be a dlopen() bug or did it expect *me* to > > free some struct from him? > > I'd guess it's within dlopen(). And the block is still reachable, so it's > not a true leak, so it's probably not worth worrying about. Thanks, well, I'm still having about 100 reachable blocks to cleanup anyway= =20 (in a medium-run test). So, please don't be so mad on me as I'm surely=20 bothering you for some more things next time as I do not (yet) understand=20 everything in there ;) However, thanks to VG, I found the most unobviouse leak in the daemon sneak= ing=20 around there for about 2 years already. I wouldn't even dare about finding = it=20 w/o VG ;-) Regards, Christian Parpart. |