[ruby-core:55879] [ruby-trunk - Bug #8386] OpenSSL thread safety

Issue #8386 has been updated by ktsj (Kazuki Tsujimoto).


MartinBosslet (Martin Bosslet) wrote:
> @ktsj Does the error occur every time you run the tests in parallel? Or only sporadically?

The latter (it is about 30-40% reproducible on my environment).


----------------------------------------
Bug #8386: OpenSSL thread safety
https://bugs.ruby-lang.org/issues/8386#change-40380

Author: dbussink (Dirkjan Bussink)
Status: Assigned
Priority: Normal
Assignee: MartinBosslet (Martin Bosslet)
Category: ext
Target version: 
ruby -v: trunk
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


As some might know, Rubinius uses a lot of MRI's C extensions that are part of stdlib and ships them as well. Rubinius however does not have a GIL, so thread safety issues in C extensions are much more important.

This patch fixes a thread safety issue in the OpenSSL extension, to allow for it being used in a concurrent scenario. This follows from the documentation of OpenSSL:

1. Is OpenSSL thread-safe?

Yes (with limitations: an SSL connection may not concurrently be used by multiple threads). On Windows and many Unix systems, OpenSSL automatically uses the multi-threaded versions of the standard libraries. If your platform is not one of these, consult the INSTALL file.

Multi-threaded applications must provide two callback functions to OpenSSL by calling CRYPTO_set_locking_callback() and CRYPTO_set_id_callback(), for all versions of OpenSSL up to and including 0.9.8[abc...]. As of version 1.0.0, CRYPTO_set_id_callback() and associated APIs are deprecated by CRYPTO_THREADID_set_callback() and friends. This is described in the threads(3) manpage.

This patch adds using the callback and thread_id functions so this works properly with Rubinius. This issue is not just theoretical, I've been able to reproduce crashes when using OpenSSL in different threads that have been fixed by this change. Rubinius already incorporated the change, but preferable I would not have to maintain a custom fork with these changes, but be able to use the MRI version without changes. I've already discussed the change with Martin and he saw no reason for objecting this change.



-- 
http://bugs.ruby-lang.org/