Bug #8386
closed
Updated by dbussink (Dirkjan Bussink) about 12 years ago
- File openssl_thread_safety. added
Updated by Anonymous almost 12 years ago
- Status changed from Open to Closed
This issue was solved with changeset r41806.
Dirkjan, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
ext/openssl/ossl.c: Provide CRYPTO_set_locking_callback() and
CRYPTO_set_id_callback() callback functions ossl_thread_id and
ossl_lock_callback to ensure the OpenSSL extension is usable in
multi-threaded environments.
[ruby-core:54900] [Bug ]Thanks, Dirkjan Bussink, for the !
Updated by ktsj (Kazuki Tsujimoto) almost 12 years ago
- File backtrace.txt added
- Status changed from Closed to Assigned
=begin
Seems r41806 introduced a test failure under Ubuntu 13.04(x86_64):
$ while :; do make TESTS='openssl -j2' test-all || cat; done
[snip]
/home/k_tsj/work/ruby/lib/test/unit/parallel.rb:37: [BUG] vm_call0_cfunc_with_frame: cfp consistency error
ruby 2.1.0dev (2013-07-06 trunk 41806) [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0004 p:---- s:0010 e:000009 CFUNC :read
c:0003 p:---- s:0008 e:000007 CFUNC :new
c:0002 p:0041 s:0005 e:000004 BLOCK /home/k_tsj/work/ruby/lib/test/unit/parallel.rb:37 [FINISH]
c:0001 p:---- s:0002 e:000001 TOP [FINISH]
/home/k_tsj/work/ruby/lib/test/unit/parallel.rb:37:in block in _run_suite' /home/k_tsj/work/ruby/lib/test/unit/parallel.rb:37:innew'
/home/k_tsj/work/ruby/lib/test/unit/parallel.rb:37:in `read'
I've attached the backtrace log.
Martin, can you check it?
=end
Updated by MartinBosslet (Martin Bosslet) almost 12 years ago
ktsj (Kazuki Tsujimoto) wrote:
I've attached the backtrace log.
Martin, can you check it?
Sure, thanks for the heads up!
Updated by MartinBosslet (Martin Bosslet) almost 12 years ago
Ok, this is gonna be fun... The error occurs in a test that triggers RSA key generation, which was implemented to run with 'rb_thread_call_without_gvl'. The OpenSSL callbacks for thread safety make use of rb_mutex_lock/rb_mutex_unlock. My initial guess is that there's a problem because the calling code runs without the GVL, but I need to analyze further to make a more educated guess.
It would help a lot if I had something isolated that reproduces the error (at least with high probability).
@ktsj (Kazuki Tsujimoto) Does the error occur every time you run the tests in parallel? Or only sporadically?
Updated by ktsj (Kazuki Tsujimoto) almost 12 years ago
MartinBosslet (Martin Bosslet) wrote:
@ktsj (Kazuki Tsujimoto) 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).
Updated by MartinBosslet (Martin Bosslet) almost 12 years ago
ktsj (Kazuki Tsujimoto) wrote:
MartinBosslet (Martin Bosslet) wrote:
@ktsj (Kazuki Tsujimoto) 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).
Thanks! Ok, that seems good enough. I'll try to extract something in isolation from that.
Updated by ko1 (Koichi Sasada) almost 12 years ago
- Status changed from Assigned to Closed
This issue was solved with changeset r42135.
Dirkjan, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
- ext/openssl/ossl.c: use system native (system provided)
thread locking APIs added by last commit.
This fixes [Bug ].
"rb_mutex_*" APIs control only "Ruby" threads.
Not for native threads.
Updated by ko1 (Koichi Sasada) almost 12 years ago
Maybe I fixed it.
Please check it.
Updated by naruse (Yui NARUSE) almost 12 years ago
ko1 (Koichi Sasada) wrote:
Maybe I fixed it.
Please check it.
I think dyn_lock_function and others also should be provided.
http://www.openssl.org/docs/crypto/threads.html
Updated by MartinBosslet (Martin Bosslet) almost 12 years ago
@ko1 (Koichi Sasada): Thank you so much for that! I think that functionality was exactly what was needed. The error happens when RSA keys are created. The code runs without the GVL in effect, and I believe the error was resulting from the fact that a different native thread was running.
@naruse (Yui NARUSE): You're right, and I also believe it would make sense to distinguish between more "modes" in the callback. I'll try to give it another try over the weekend. But please, if you have something (planned) already, let me know and we could try to combine our efforts!
Updated by ko1 (Koichi Sasada) almost 12 years ago
(2013/07/24 19:37), MartinBosslet (Martin Bosslet) wrote:
@naruse (Yui NARUSE): You're right, and I also believe it would make sense to distinguish between more "modes" in the callback. I'll try to give it another try over the weekend. But please, if you have something (planned) already, let me know and we could try to combine our efforts!
I did. Please check it.
--
// SASADA Koichi at atdot dot net
Updated by tknerr (Torben Knerr) about 10 years ago
Might be a regression of this?