[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Looking for config option to stop use of CryptoAPI (TSVN 1.7.1)

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Wed, 23 Nov 2011 22:37:48 +0100

On 23.11.2011 17:50, Joel Jirak wrote:
> It's still crashing in the latest nightly, 1.7.1.22294, and I think I
> know at least one reason why.
>
> All the crashes -- I have many stack traces -- occur deep in the
> bowels of OpenSSL, when ERR_unload_strings() calls int_err_del_item().
> (A debug build will assert at the same location too.)
>
> The call to int_err_del_item() is surround by a lock call
> (CRYPTO_w_lock()), which does nothing. It does nothing because when
> neon initializes OpenSSL in ne__ssl_init(), it doesn't call
> CRYPTO_set_locking_callback() because it's #ifdef'ed out since neon
> doesn't have a WIN32 lock implementation.
>
> http://www.openssl.org/docs/crypto/threads.html: "Multi-threaded
> applications will crash at random if [the locking function] is not
> set."
>
> Possible solutions:
> 1. Get the neon maintainers to add a WIN32 lock implementation. They
> could either use the apr lock implementation (like serf does) or just
> imitate the win32 implementation given in OpenSSL's mttest.c
> 2. Have TortoiseSVN provide its own win32 lock implementation
> (imitate mttest.c) and initialize OpenSSL itself just before or after
> calling ne_sock_init(), but don't do this when using serf.
> 3. Something else at a higher level in the TSVN code so that _every_
> operation that might access OpenSSL is mutex'ed?
>
> This thread race condition may have been around for a long time. I
> think it's worse in the repo-browser case because that code kicks off
> several worker threads.
>
> And to confirm my working theory that the problem is with neon, I
> opened the repo-browser twenty times with http-library=serf. Result:
> no crashes

Thanks for the very detailed analysis. I think you really found the
problem here.
I've patched neon in the TSVN build.
Can you please try the next nightly build and check whether that patch
actually works as expected? My first tests look good, but I never had
these crashes myself.
(nightly build >= r22303).

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2885207
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-11-23 22:38:02 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.