On Fri, Jul 06, 2007 at 10:16:05PM +0200, Stefan Küng wrote:
> Joe Orton wrote:
...
> >(Looking at the code, ra_dav should really just call ne_sock_init() once
> >in svn_ra_dav__init, I think; it's unnecessary/wrong to call it each
> >time an RA session is opened.)
>
> Hmmm - then ne_sock_init() really initializes more than just a socket?
> Maybe the function should be renamed to ne_global_init() or something
> like that to avoid confusion?
I'd have hoped that reading the documentation would make some of that
confusion go away :) In retrospect, yes, _global_init() would make more
sense; not sure if it's worth renaming at this point.
> The reason I got confused here is because I always got a lot of memory
> leaks as soon as I access a repository via http/https (i.e., when neon
> is used). First I thought it was because ne_sock_exit() isn't called for
> every ne_sock_init(), but that didn't solve the leaks. Digging a little
> bit further I discovered that OpenSSL isn't shut down at all, and I had
> to do that myself before exiting my app.
> Maybe that should be documented somewhere too? And AFAIK the Subversion
> client doesn't shut down OpenSSL either - it should call:
> ERR_free_strings();
> EVP_cleanup();
> CRYPTO_cleanup_all_ex_data();
> before exiting (of course, only if it's linked against OpenSSL). Even if
> OpenSSL wasn't initialized (e.g., because no network connection was
> needed), those cleanup calls won't hurt because they just won't do anything.
Unless this stuff has been fixed in OpenSSL recently, those are all
either irreversible operations or are not ref-counted and will
potentially break any other code which uses OpenSSL within the process.
Doing it at application level is basically all that is feasible.
Really, my best advice is "don't use OpenSSL in threaded application" -
see also neon's GnuTLS support.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 9 21:36:47 2007