from Jan:
I'm not exactly saying that "DH_free(DH_new()) leaks memory when in a DLL on Solaris", what I'm saying is that libcrypto does not free memory that it should in "#pragma fini(xxx)". I assume there is some memory allocated first time DH_new() is used and that memory is never freed on dlclose(). So, if I do DH_free(DH_new()) in dlopen'ed library that I then dlclose, there is a leak. link to the RT entry: http://rt.openssl.org/Ticket/Display.html?id=2363&user=guest&pass=guest if I run the test like this (different code than in RT): test.c (build as "gcc -o test -ldl test.c"): #include <dlfcn.h> #include <link.h> #include <stdlib.h> int main() { void (*run)(); while (1) { void *handle = dlopen("./run.so", RTLD_NOW); run = (void (*)()) dlsym(handle, "run"); (*run)(); dlclose(handle); } return (0); } run.c (build as "gcc --shared -lcrypto -fPIC -o run.so run.c"): #include <openssl/dh.h> int run() { DH_free(DH_new()); } on Linux, I'm leaking megabytes of memory within seconds: $ openssl version OpenSSL 1.0.1i 6 Aug 2014 $ ./test & $ top -b -p $( pgrep test ) <output edited> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21888 pechanec 20 0 17552 2900 504 R 100.0 0.0 0:01.18 test 21888 pechanec 20 0 23228 8816 648 R 99.9 0.1 0:04.18 test 21888 pechanec 20 0 28904 14472 648 R 100.0 0.2 0:07.19 test 21888 pechanec 20 0 34448 19872 504 R 99.9 0.3 0:10.19 test^C it is a generic OpenSSL libcrypto problem. Not one that most users will ever see but still a bug. I assume there might be more leaks like that in implementation of other algorithms. cheers, Jan. -- Jan Pechanec <jan.pecha...@oracle.com> -- Rich Salz, OpenSSL dev team; rs...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2363 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev