Project

General

Profile

Actions

Bug #13834

closed

RubyGems test suite occasionally changes working directory and breaks the rest of test suite

Added by vo.x (Vit Ondruch) over 6 years ago. Updated over 4 years ago.

Status:
Closed
Target version:
-
ruby -v:
ruby 2.5.0dev (2017-08-18 trunk 59616) [x86_64-linux]
[ruby-core:82438]

Description

From time to time, RubyGems test suite changes working directory, which breaks rest of Ruby tests suite. It all starts like this:

[ 7096/17125] TestGemRemoteFetcher#test_do_not_allow_invalid_client_cert_auth_connection = 0.01 sLeaked file descriptor: TestGemRemoteFetcher#test_do_not_allow_invalid_client_cert_auth_connection: 21 : #<TCPServer:fd 21, AF_INET, 0.0.0.0, 45301>
Leaked file descriptor: TestGemRemoteFetcher#test_do_not_allow_invalid_client_cert_auth_connection: 22 : #<TCPServer:fd 22, AF_INET6, ::, 45301>
Leaked file descriptor: TestGemRemoteFetcher#test_do_not_allow_invalid_client_cert_auth_connection: 23 : #<IO:fd 23>
Leaked file descriptor: TestGemRemoteFetcher#test_do_not_allow_invalid_client_cert_auth_connection: 24 : #<IO:fd 24>
Leaked thread: TestGemRemoteFetcher#test_do_not_allow_invalid_client_cert_auth_connection: #<Thread:0x000056191465fe40@/home/hsbt/chkbuild/tmp/build/20170818T003002Z/ruby/test/rubygems/test_gem_remote_fetcher.rb:1025 sleep>
Environment variable changed: TestGemRemoteFetcher#test_do_not_allow_invalid_client_cert_auth_connection : "GEM_PRIVATE_KEY_PASSPHRASE" added
Environment variable changed: TestGemRemoteFetcher#test_do_not_allow_invalid_client_cert_auth_connection : "GEM_SPEC_CACHE" added
Environment variable changed: TestGemRemoteFetcher#test_do_not_allow_invalid_client_cert_auth_connection : "HOME" changed : "/home/hsbt" -> "/home/hsbt/chkbuild/tmp/build/20170818T003002Z/tmp/test_rubygems_29019/userhome"

and results in errors such as:

  2) Failure:
TestMkmf::TestConfig#test_dir_config [/home/hsbt/chkbuild/tmp/build/20170818T003002Z/ruby/test/mkmf/test_config.rb:12]:
assert_separately failed with error message
pid 2383 exit 1
| /home/hsbt/chkbuild/tmp/build/20170818T003002Z/ruby/lib/mkmf.rb:228:in `expand_path': No such file or directory - getcwd (Errno::ENOENT)
| 	from /home/hsbt/chkbuild/tmp/build/20170818T003002Z/ruby/lib/mkmf.rb:228:in `<module:MakeMakefile>'
| 	from /home/hsbt/chkbuild/tmp/build/20170818T003002Z/ruby/lib/mkmf.rb:48:in `<top (required)>'
| 	from -:1:in `require'

You can find the full log rubyci.org 1.

Updated by shevegen (Robert A. Heiler) over 6 years ago

I think the github "ticket" is not as useful as the issue track here; I may mistakingly remember
but I think that some of the ruby core team said so. Where github may help of course are
patches and pull requests attached to.

The error "No such file or directory - getcwd (Errno::ENOENT)" may have come from some operation
removing a directory so perhaps the logic in the build-up chain is incorrect. BTW I also see
this on ruby-gnome sometimes, with paths such as "/home/hsbt/chkbuild/tmp/build/" (or ruby-gnome,
it's kou though, not hsbt) - is this general that this path information is included somewhere? It
may be easier to instead use some ENV variable or something, since it is strange that other users
get to see such paths in general. (I just noticed it in ruby-gnome a while ago, now I notice it
here.)

Updated by vo.x (Vit Ondruch) over 6 years ago

So far, I think the test never reaches this 1 line for some reason. Or if it reaches it, it is not executed properly. Then the temporary directory is cleaned up and the test suite starts to fail.

Updated by hsbt (Hiroshi SHIBATA) over 5 years ago

  • Status changed from Open to Assigned
  • Assignee set to hsbt (Hiroshi SHIBATA)

Updated by hsbt (Hiroshi SHIBATA) about 5 years ago

  • Status changed from Assigned to Feedback

@vo.x (Vit Ondruch)

Do you still have this issue? I couldn't reproduce this on Fedora 27 and 28 of RubyCI.

Actions #7

Updated by jeremyevans0 (Jeremy Evans) over 4 years ago

  • Status changed from Feedback to Closed
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0