On May 16 07:46, David Schwartz wrote: > > Shouldn't this code be removed on all platforms? It seems that the > issue Cygwin is having could occur on any platform, perhaps it just > happens not to on Win32 with the default locking callbacks. > > It should be obvious that calling any OpenSSL functions that require > the locking callbacks to be intact would be illegal at thread attach > time. That would give the application no opportunity to register the > callbacks or set up any data structures they require. > > It seems the same argument should apply here. What if the > application has already torn down the structures required to make > the callbacks work? My understanding was that fundamentally, OpenSSL > never ran any of its own threads or 'magically' called its own > functions so the application had complete control over when OpenSSL > functionality was invoked. This allows the application to set up and > tear down any of the callback functions. This includes both the > threaded functions and memory management. > > This seems a gratuitous violation of fundamental API design principles. > > The documentation at > http://www.openssl.org/docs/crypto/ERR_remove_state.html > says: "Since error queue data structures are allocated automatically > for new threads, they must be freed when threads are terminated in > order to avoid memory leaks." > > So non-broken applications are already calling this function at a > time they know it is safe to do so. Why call it at a potentially > dangerous time outside of the control over the application that > manages the library and thread lifetimes?
I agree. I'm not sure this will potentially crash on native Win32, too. But I didn't want to break another platform so I just created a patch for Cygwin. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
