Created attachment 405129 [details] Patch to fix memory leak Description of problem: I'm unsure of how "correct" this patch is, but it should be a step in the right direction. The problem is that the memory allocated per thread is not free'd when the library is unloaded. The comments for free_key_mem states that is is called upon thread termination, but a breakpoint on it in gdb does not get hit at all. This patch adds the call to the free_key_mem to fini and also adds a check to check_free to avoid a possible NULL dereference (this check may be better in free_key_mem). I've rebuilt the RPM from Fedora with this patch (which seems to do make check, but I don't know how rigorous this is) and all went well. Unfortunately, LD_LIBRARY_PATH on such a low-level library makes things not work at all and I'm also cautious about actually installing this change on any of my live machines due to how bad things would be if the patch is wrong. Thanks. Version-Release number of selected component (if applicable): glibc-2.11.90-17.i686
Please provide a test case.
Created attachment 405312 [details] Minimal test case for memory leak Compilation command (minimal): gcc -g -o dlerror_memleak dlerror_memleak.c -ldl With `-lpthread', there is leaked memory (back trace below). Without, there isn't any. ==10067== 20 bytes in 1 blocks are still reachable in loss record 1 of 1 ==10067== at 0x4027F1B: calloc (vg_replace_malloc.c:418) ==10067== by 0x403A0A5: _dlerror_run (dlerror.c:142) ==10067== by 0x4039B70: dlopen@@GLIBC_2.1 (dlopen.c:88) ==10067== by 0x8048542: main (main.c:14)
Ping?
Can you reproduce the issue with the current version? (glibc-2.12.90-3 at the moment)
I'll have my machine rebuild for F-13 tonight (don't want to play with *too* much fire) and test when I get back from $DAYJOB tomorrow, and before if I have time then.
Cursory look at the file looks to still be leaking, I'll get hard results though.
Created attachment 428168 [details] Shell output Ah, the build was quick. It's the test suite that takes forever. Yes, the leak is still there. Log attached (valgrind-c is valgrind with some options I find useful on by default). % rpm -q glibc glibc-2.12.90-3.x86_64
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Patch was rejected upstream since it only releases memory for the one thread where the destructor of libdl gets called. Doesn't fix multi-threaded applications.