Bug 1257578

Summary: thread lock within require
Product: [Fedora] Fedora Reporter: Aleksandar Kostadinov <akostadi>
Component: rubyAssignee: Jeroen van Meeuwen <vanmeeuwen+fedora>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: jstribny, mmorsi, mtasaka, s, tagoh, vanmeeuwen+fedora, vondruch
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-27 14:05:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Aleksandar Kostadinov 2015-08-27 11:42:36 UTC
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 12:21:13 UTC
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 13:30:10 UTC
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 13:49:57 UTC
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 14:05:49 UTC
https://github.com/pry/pry/issues/1465