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?
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.
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.
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.
https://github.com/pry/pry/issues/1465