|
From: Christian P. <tr...@ge...> - 2006-12-26 18:17:30
|
Hi all, here's another issue I'm fighting with. I explicitely dlclose()'d my handle= to=20 the dlopen()'d shared libraries I am using. However, valgrind found some=20 interesting bits deep inside that were allocated but obviousely not really= =20 freed. Although, this app dlopen()ed six shared libraries, (all in the very same w= ay)=20 but only two reachable blocks are warned about by valgrind. =3D=3D17835=3D=3D 32 bytes in 1 blocks are still reachable in loss record 1= of 2 =3D=3D17835=3D=3D at 0x4A1EC0F: calloc (vg_replace_malloc.c:279) =3D=3D17835=3D=3D by 0x795F5BA: (within /lib64/libdl-2.5.so) =3D=3D17835=3D=3D by 0x795F151: dlopen (in /lib64/libdl-2.5.so) =3D=3D17835=3D=3D by 0x73C4C5A:=20 System::Runtime::TLibraryLoader::loadLibrary(System::TStringBase<char>=20 const&) (TLibraryLoader.unix.cpp:97) =3D=3D17835=3D=3D by 0x4C61EA0: yacs::TServer::loadModule(System::TStrin= gBase<char>=20 const&) (TServer.cpp:240) =3D=3D17835=3D=3D by 0x421A6C: TServerApplication::loadModules(yacs::TSe= rver*)=20 (yacsd.cpp:339) =3D=3D17835=3D=3D by 0x422405: TServerApplication::spawnServer() (yacsd.= cpp:386) =3D=3D17835=3D=3D by 0x4263B2: TServerApplication::serve(System::TVarDat= a const&)=20 (yacsd.cpp:457) =3D=3D17835=3D=3D by 0x4291D8: TServerApplication::load() (yacsd.cpp:139) =3D=3D17835=3D=3D by 0x6F808E6: System::TApplication::run() (TApplicatio= n.cpp:234) =3D=3D17835=3D=3D by 0x426157: main (yacsd.cpp:470) =3D=3D17835=3D=3D =3D=3D17835=3D=3D =3D=3D17835=3D=3D 328 bytes in 1 blocks are still reachable in loss record = 2 of 2 =3D=3D17835=3D=3D at 0x4A1FB1E: malloc (vg_replace_malloc.c:149) =3D=3D17835=3D=3D by 0x401037D: add_to_global (in /lib64/ld-2.5.so) =3D=3D17835=3D=3D by 0x40107A5: dl_open_worker (in /lib64/ld-2.5.so) =3D=3D17835=3D=3D by 0x400C6E5: _dl_catch_error (in /lib64/ld-2.5.so) =3D=3D17835=3D=3D by 0x4010006: _dl_open (in /lib64/ld-2.5.so) =3D=3D17835=3D=3D by 0x795F1D9: (within /lib64/libdl-2.5.so) =3D=3D17835=3D=3D by 0x400C6E5: _dl_catch_error (in /lib64/ld-2.5.so) =3D=3D17835=3D=3D by 0x795F55C: (within /lib64/libdl-2.5.so) =3D=3D17835=3D=3D by 0x795F151: dlopen (in /lib64/libdl-2.5.so) =3D=3D17835=3D=3D by 0x73C4C5A:=20 System::Runtime::TLibraryLoader::loadLibrary(System::TStringBase<char>=20 const&) (TLibraryLoader.unix.cpp:97) =3D=3D17835=3D=3D by 0x4C61EA0: yacs::TServer::loadModule(System::TStrin= gBase<char>=20 const&) (TServer.cpp:240) =3D=3D17835=3D=3D by 0x421A6C: TServerApplication::loadModules(yacs::TSe= rver*)=20 (yacsd.cpp:339) =3D=3D17835=3D=3D by 0x422405: TServerApplication::spawnServer() (yacsd.= cpp:386) =3D=3D17835=3D=3D by 0x4263B2: TServerApplication::serve(System::TVarDat= a const&)=20 (yacsd.cpp:457) =3D=3D17835=3D=3D by 0x4291D8: TServerApplication::load() (yacsd.cpp:139) =3D=3D17835=3D=3D by 0x6F808E6: System::TApplication::run() (TApplicatio= n.cpp:234) =3D=3D17835=3D=3D by 0x426157: main (yacsd.cpp:470) =3D=3D17835=3D=3D =3D=3D17835=3D=3D LEAK SUMMARY: =3D=3D17835=3D=3D definitely lost: 0 bytes in 0 blocks. =3D=3D17835=3D=3D possibly lost: 0 bytes in 0 blocks. =3D=3D17835=3D=3D still reachable: 360 bytes in 2 blocks. =3D=3D17835=3D=3D suppressed: 0 bytes in 0 blocks. What could be the reason for this? and if not a bug of either package, how = can=20 I work around this? Thanks in advance, Christian Parpart. |
|
From: John R.
|
> Although, this app dlopen()ed six shared libraries, (all in the very same way) > but only two reachable blocks are warned about by valgrind. > > ==17835== 32 bytes in 1 blocks are still reachable in loss record 1 of 2 > ==17835== at 0x4A1EC0F: calloc (vg_replace_malloc.c:279) > ==17835== by 0x795F5BA: (within /lib64/libdl-2.5.so) > ==17835== by 0x795F151: dlopen (in /lib64/libdl-2.5.so) > ==17835== 328 bytes in 1 blocks are still reachable in loss record 2 of 2 > ==17835== at 0x4A1FB1E: malloc (vg_replace_malloc.c:149) > ==17835== by 0x401037D: add_to_global (in /lib64/ld-2.5.so) > ==17835== by 0x40107A5: dl_open_worker (in /lib64/ld-2.5.so) My experience is that the glibc maintainers do not listen to complaints about leaks unless you do one of two things: 1) Present a small standalone example (say, at most 100 lines) which is obviously correct externally but which grows without bound when run; or, 2) Run with debug info so that tracebacks include the filename and line numbers of glibc code. Then do the analysis that shows where the leak happened and why, provide a patch which fixes the leak, and submit a testcase which fails before and succeeds after the patch. [There is a bonus if the testcase is already a glibc internal testcase.] There have been data structures in dlopen, such as the lists of which modules should be searched (and in what order) during symbol resolution, that are shared [particularly tails of lists] and not completely reference counted. The correct behavior in some cases is sufficiently arcane that it is easly to regard allegations of leaks as low priority. The way to increase the priority is to submit testcases. -- |