From: ethan_j_brown@hotmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:81670] [Ruby trunk Bug#11033] OpenSSL related threading issues in Ruby 2.1 and 2.2
Date: Wed, 14 Jun 2017 01:23:13 +0000 [thread overview]
Message-ID: <redmine.journal-65361.20170614012313.ebb73052b213ecc3@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-11033.20150404000843@ruby-lang.org
Issue #11033 has been updated by Iristyle (Ethan Brown).
Also seeing this issue crop up in AppVeyor - specifically under Ruby 2.4 testing. We haven't seen this in previous Ruby builds (not that RubyInstaller changed how Ruby is built in the 2.4 installers).
Such an example is at https://ci.appveyor.com/project/puppetlabs/puppet/build/4.1.0.5694/job/jkk5rbf49ou92yc8
----------------------------------------
Bug #11033: OpenSSL related threading issues in Ruby 2.1 and 2.2
https://bugs.ruby-lang.org/issues/11033#change-65361
* Author: tknerr (Torben Knerr)
* Status: Open
* Priority: Normal
* Assignee: openssl
* Target version:
* ruby -v: 2.1.5p273, 2.2.1p85
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
I'm experiencing some problems with multiple https connections in Ruby 2.1 and 2.2, whilst in Ruby 2.0 everything is working fine.
This happens on a Windows 7 (64-bit) box in the context of installing multiple gems in parallel via bundlers `BUNDLE_JOBS=<n>` setting.
What I see are multiple `OpenSSL::SSL::SSLError: SSL_read: cert already in hash table` warnings and at some more or less random point it bails out because it cannot install a gem. When I repeat the `bundle install` command it will get past that gem and fail at a later one. I can repeat until all gems are installed.
This is the stacktrace I get for every of the ssl warnings:
```
...
Installing polyglot 0.3.5
4: polyglot (0.3.5) from X:/home/.gem/ruby/2.2.0/specifications/polyglot-0.3.5.gemspec
OpenSSL::SSL::SSLError: SSL_read: cert already in hash table
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/openssl/buffering.rb:182:in `sysread_nonblock'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/openssl/buffering.rb:182:in `read_nonblock'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/net/protocol.rb:153:in `rbuf_fill'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/net/protocol.rb:134:in `readuntil'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/net/protocol.rb:144:in `readline'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/net/http/response.rb:39:in `read_status_line'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/net/http/response.rb:28:in `read_new'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/net/http.rb:1414:in `block in transport_request'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/net/http.rb:1411:in `catch'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/net/http.rb:1411:in `transport_request'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/net/http.rb:1384:in `request'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/rubygems/request.rb:154:in `perform_request'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/rubygems/request.rb:109:in `fetch'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/rubygems/remote_fetcher.rb:346:in `request'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/rubygems/remote_fetcher.rb:231:in `fetch_http'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/rubygems/remote_fetcher.rb:247:in `fetch_http'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/rubygems/remote_fetcher.rb:267:in `fetch_path'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/rubygems/remote_fetcher.rb:302:in `cache_update_path'
X:/tools/ruby-2.2.1/lib/ruby/2.2.0/rubygems/remote_fetcher.rb:168:in `download'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/rubygems_integration.rb:544:in `download_gem'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/fetcher.rb:63:in `download_gem_from_uri'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/source/rubygems.rb:370:in `fetch_gem'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/source/rubygems.rb:98:in `install'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/installer.rb:107:in `install_gem_from_spec'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/installer.rb:287:in `block in install_in_parallel'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/worker.rb:55:in `call'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/worker.rb:55:in `apply_func'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/worker.rb:50:in `block in process_queue'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/worker.rb:47:in `loop'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/worker.rb:47:in `process_queue'
X:/tools/ruby-2.2.1/lib/ruby/gems/2.2.0/gems/bundler-1.9.2/lib/bundler/worker.rb:22:in `block (2 levels) in initialize'
...
```
This is originally reported here (with a bit more details):
https://github.com/bundler/bundler/issues/3545
Any ideas?
Might it be a regression of #8386?
--
https://bugs.ruby-lang.org/
next prev parent reply other threads:[~2017-06-14 1:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-11033.20150404000843@ruby-lang.org>
2015-04-04 0:08 ` [ruby-core:68748] [Ruby trunk - Bug #11033] [Open] OpenSSL related threading issues in Ruby 2.1 and 2.2 mail
2015-04-04 10:52 ` [ruby-core:68754] [Ruby trunk - Bug #11033] " mail
2015-04-04 12:50 ` [ruby-core:68755] " mail
2015-09-13 3:23 ` [ruby-core:70774] " zzak
2017-06-14 1:23 ` ethan_j_brown [this message]
2017-06-14 4:57 ` [ruby-core:81678] [Ruby trunk Bug#11033] " k
2017-06-19 13:41 ` [ruby-core:81722] " ethan_j_brown
2017-06-19 15:26 ` [ruby-core:81723] " k
2017-06-19 15:37 ` [ruby-core:81725] " usa
2017-06-23 21:28 ` [ruby-core:81760] " ethan_j_brown
2017-08-03 13:43 ` [ruby-core:82229] " nagachika00
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-65361.20170614012313.ebb73052b213ecc3@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).