That is my point, that "one-off" leaks in DLLs are not one-off leaks at all. While statically linking against the C runtime library certainly works around the issue (at least on Windows, and as you say on Mac) it is a poor resolution for a memory leak as it sacrifices the benefits of using a DLL. Since OpenSSL doesn't statically link against the C runtime on Windows it's a further indication that the issue raised by Steffen is in fact the leak that he presumed.
Dismissing leaks as one-off's is a pet peeve of mine. The notion of one-off leaks in an executable is arguably passable, but becomes a plain old memory leak just like any other when packaged as a library. Regards, Steven -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Juran Sent: Wednesday, 16 November 2005 1:44 PM To: openssl-users@openssl.org Subject: Re: SSL_library_init - missing 36 bytes after cleanup On Nov 15, 2005, at 9:00 PM, Steven Reddie wrote: > I understand about one-off leaks, but we're talking about a > dynamically loadable library when we're talking about OpenSSL. > > What would happen if an application did something like this: > > for (int i=0; i<1000; i++) > { > hSSL = LoadLibrary("libssl.so") > fn = GetSymbol(hSSL, SSL_COMP_get_compression_methods); > fn(); > ReleaseLibrary(hSSL); > } > > Is it still a one-off leak? > > Unfreed memory is not a problem in an application, but it's a whole > different story in a library. I agree that the rules are different for shared libraries, and if ssl hasn't cleaned up after itself completely when the call to ReleaseLibrary() returns, it's a leak. My experience with dynamically linked libraries is limited to Mac OS' Code Fragment Manager, where I've avoided some issues by linking plugins against the standard library statically, so each one gets its own malloc pool. I also generally work in C++, where I can use statically allocated objects with constructors and destructors, such as smart pointers. > Another example of such problems in libraries is atexit(). atexit() > works great in an application, but use it in libssl.so when used in > the code above and you'll most likely get a hard crash when the > application terminates because the handler is still registered with > the C runtime library, but the code has been unloaded. If OpenSSL claims to be usable when dynamically loaded, then it's a bug in OpenSSL. Otherwise, it's a bug in the code that's loading it. Josh > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Juran > Sent: Wednesday, 16 November 2005 12:38 PM > To: openssl-users@openssl.org > Subject: Re: SSL_library_init - missing 36 bytes after cleanup > > On Nov 15, 2005, at 7:29 PM, Steven Reddie wrote: > >> David, >> >> If 36 bytes are being dynamically allocated and not being freed how >> is it not a leak? >> >> Steven > > Because it only happens once. > > Imagine that when you shut off a faucet, water drips out for the next > ten seconds and then stops. That's not a leak, and it's not a > problem. > What would be (both a problem and a leak) is water continually > dripping at a regular frequency. > > The 36 bytes is not considered a leak because it's acquired only once > as a part of initialization, not proportionally to the use of your > application. > And it does get released -- when the process exits. :-) > > If it's a problem, maybe you should invest in a RAM upgrade... :-D ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
