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
Joel Jirak
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2885156
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-11-23 17:51:04 CET