|
From: Christian P. <tr...@ge...> - 2005-08-24 11:40:03
|
Hi all, I'm having the following backtrace in my server's shutdown summary of VG: =3D=3D13271=3D=3D 16 bytes in 1 blocks are still reachable in loss record 8= of 56 =3D=3D13271=3D=3D at 0x1B905E1A: calloc (in /usr/lib/valgrind/vgpreload_= memcheck.so) =3D=3D13271=3D=3D by 0x1CFCB3A3: (within /lib/libdl-2.3.5.so) =3D=3D13271=3D=3D by 0x1CFCAD60: dlopen (in /lib/libdl-2.3.5.so) =3D=3D13271=3D=3D by 0x1C56A580: System::Runtime::TLibrary::TLibrary(Sys= tem::TStringBase<char> const&, System::TStringBase<char> const&) (TLibrary.= cpp:38) =3D=3D13271=3D=3D by 0x1C56B6A1: System::Runtime::TLibraryMgr::loadLibra= ry(System::TStringBase<char> const&) (TLibraryMgr.cpp:92) =3D=3D13271=3D=3D by 0x1BA73A63: yacs::TServer::loadModule(System::TStri= ngBase<char> const&, System::TStringBase<char> const&) (TServer.cpp:518) =3D=3D13271=3D=3D by 0x1BA73748: yacs::TServer::loadModule(System::TStri= ngBase<char> const&) (TServer.cpp:511) =3D=3D13271=3D=3D by 0x806287B: loadModules(yacs::TServer*) (yacsd.cpp:2= 49) =3D=3D13271=3D=3D by 0x8064E14: spawnServer() (yacsd.cpp:310) =3D=3D13271=3D=3D by 0x80659FA: main (yacsd.cpp:388) Well, I'm pretty pretty sure that I dlclose()'d every=20 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? Regards, Christian Parpart. p.s.: this time, it has been run from an x86 (not amd64) |
|
From: Nicholas N. <nj...@cs...> - 2005-08-24 14:13:26
|
On Wed, 24 Aug 2005, Christian Parpart wrote: > I'm having the following backtrace in my server's shutdown summary of VG: > > ==13271== 16 bytes in 1 blocks are still reachable in loss record 8 of 56 > ==13271== at 0x1B905E1A: calloc (in /usr/lib/valgrind/vgpreload_memcheck.so) > ==13271== by 0x1CFCB3A3: (within /lib/libdl-2.3.5.so) > ==13271== 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. N |
|
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. |