Bug 1257578 - thread lock within require
thread lock within require
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: ruby (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeroen van Meeuwen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-27 07:42 EDT by Aleksandar Kostadinov
Modified: 2015-08-27 10:05 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-27 10:05:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksandar Kostadinov 2015-08-27 07:42:36 EDT
Description of problem:
Hello, doing a threaded app. It's actually one uploader thread thread that does scp and then attach logs to TCMS.

Issue is that with fedora 22 version of Ruby 2.2.2 my thread hangs forever and with stock ruby 2.2.2 as installed by `rvm` thread never locks.

It's locking within an async XMLRPC call to TCMS where a require line is inside a method. If I move the require at the file top, then it is not locking.

Unfortunately I could not write a simple reproducer. All I try is working under irb. Perhaps it's something timing sensitive. I don't know.

Version-Release number of selected component (if applicable):
ruby-2.2.2-40.fc22.x86_64

How reproducible:
Only on my laptop in a VM, could not reproduce on 2 other VMs.

Steps to Reproduce:
1. 
2.
3.

Actual results:
> @attacher.status
> => "sleep"
> @attacher.backtrace
> => ["/usr/share/ruby/monitor.rb:185:in `lock'",
> "/usr/share/ruby/monitor.rb:185:in `mon_enter'",
> "/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:39:in `require'",
> "/usr/share/ruby/rexml/source.rb:17:in `create_from'",
> "/usr/share/ruby/rexml/parsers/baseparser.rb:128:in `stream='",
> "/usr/share/ruby/rexml/parsers/baseparser.rb:117:in `initialize'",
> "/usr/share/ruby/rexml/parsers/streamparser.rb:8:in `new'",
> "/usr/share/ruby/rexml/parsers/streamparser.rb:8:in `initialize'",
> "/usr/share/ruby/rexml/document.rb:241:in `new'",
> "/usr/share/ruby/rexml/document.rb:241:in `parse_stream'",
> "/usr/share/ruby/xmlrpc/parser.rb:742:in `parse'",
> "/usr/share/ruby/xmlrpc/parser.rb:486:in `parseMethodResponse'",
> "/usr/share/ruby/xmlrpc/client.rb:321:in `call2_async'",
> "/home/avalon/v3/lib/tcms/tcms.rb:147:in `call2_async'",
> "/home/avalon/v3/lib/tcms/tcms_manager.rb:190:in `link_logs_to_tcms_async'",
> "/home/avalon/v3/lib/tcms/tcms_manager.rb:176:in `handle_attach'",
> "/home/avalon/v3/lib/tcms/tcms_manager.rb:28:in `block in initialize'"]


Expected results:
nothing like that above ^

Additional info:
Given I cannot create a reproducer, any advice how can I debug this kind of issue?
Comment 2 Aleksandar Kostadinov 2015-08-27 08:21:13 EDT
I could find a little bit more. When I pry once I detect thread is locked, I did:
> Kernel::RUBYGEMS_ACTIVATION_MONITOR.mon_exit

After that the other thread continues running. Looks like main thread is for some reason holding the lock and the other thread is waiting forever. I have no idea how and why it happens. I never touch Kernel::RUBYGEMS_ACTIVATION_MONITOR.
Comment 3 Aleksandar Kostadinov 2015-08-27 09:30:10 EDT
FYI isolated this to a `binding.pry` call. After the call I get the activation monitor owned by current thread and lock never released:
> Kernel::RUBYGEMS_ACTIVATION_MONITOR.instance_variable_get(:@mon_owner) == Thread.current

Probably something related to pry and maybe has to do with some installed plug-ins.
Comment 4 Aleksandar Kostadinov 2015-08-27 09:49:57 EDT
Further tracked down to the installation of `yard-cucumber` gem. At this point I think there's nothing fedora specific with the issue. More to do with `pry` IMHO.
Comment 5 Aleksandar Kostadinov 2015-08-27 10:05:49 EDT
https://github.com/pry/pry/issues/1465

Note You need to log in before you can comment on or make changes to this bug.