Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

undefined method `fetch_or_store' for {}:Hash (RSpec 3.3.0) #1999

Closed
e2 opened this issue Jun 17, 2015 · 14 comments
Closed

undefined method `fetch_or_store' for {}:Hash (RSpec 3.3.0) #1999

e2 opened this issue Jun 17, 2015 · 14 comments

Comments

@e2
Copy link
Contributor

e2 commented Jun 17, 2015

I wanted to debug, but I'm out of time - sorry.

I'm getting it on 3.3.0 here:

https://travis-ci.org/guard/listen/jobs/67160910#L863

How to reproduce locally:

  1. Clone guard/listen repository at v2.10.1
  2. bundle install
  3. CI=true rspec spec/acceptance/tcp_spec.rb:40

Fails here: rspec-core-3.3.0/lib/rspec/core/memoized_helpers.rb:295

Also:

  • works if I lock rspec-core to 3.2.0
  • works with the following master checkouts:
  gem 'rspec', github: 'rspec/rspec'
  gem 'rspec-core', github: 'rspec/rspec-core'
  gem 'rspec-expectations', github: 'rspec/rspec-expectations'
  gem 'rspec-mocks', github: 'rspec/rspec-mocks'
  gem 'rspec-support', github: 'rspec/rspec-support'

so I guess this is fixed but not released.

@myronmarston
Copy link
Member

I can't reproduce. This is the output I'm getting:

➜  listen git:(9ee289f) CI=true bundle exec rspec spec/acceptance/tcp_spec.rb:40
[Coveralls] Set up the SimpleCov formatter.
[Coveralls] Using SimpleCov's default settings.
Run options: include {:focus=>true, :locations=>{"./spec/acceptance/tcp_spec.rb"=>[40]}}

Randomized with seed 4296

Listen::Listener
  when recipient
    should process addition of "file.rb"
  when broadcaster
    should process addition of "file.rb"

Finished in 4.15 seconds (files took 0.48068 seconds to load)
2 examples, 0 failures

Randomized with seed 4296

[Coveralls] Submitting with config:
{
  "environment": {
    "pwd": "/Users/myron/code/listen",
    "rails_root": null,
    "simplecov_root": "/Users/myron/code/listen",
    "gem_version": "0.8.1"
  },
  "git": {
    "head": {
      "id": "9ee289f19b80041e926a0a6c4e236d9581b29961",
      "author_name": "Cezary Baginski",
      "author_email": "cezary@chronomantic.net",
      "committer_name": "Cezary Baginski",
      "committer_email": "cezary@chronomantic.net",
      "message": "Release 2.10.1"
    },
    "branch": "HEAD\n",
    "remotes": [
      {
        "name": "origin",
        "url": "git@github.com:guard/listen.git"
      }
    ]
  },
  "service_name": null,
  "service_number": null,
  "service_job_id": null,
  "service_build_url": null,
  "service_branch": null,
  "service_pull_request": null
}
[Coveralls] Submitting to https://coveralls.io/api/v1
Coveralls encountered an exception:
RestClient::UnprocessableEntity
422 Unprocessable Entity
/Users/myron/.gem/ruby/2.1.5/gems/rest-client-1.8.0/lib/restclient/abstract_response.rb:74:in `return!'
/Users/myron/.gem/ruby/2.1.5/gems/rest-client-1.8.0/lib/restclient/request.rb:495:in `process_result'
/Users/myron/.gem/ruby/2.1.5/gems/rest-client-1.8.0/lib/restclient/request.rb:421:in `block in transmit'
/Users/myron/.rubies/ruby-2.1.5/lib/ruby/2.1.0/net/http.rb:853:in `start'
/Users/myron/.gem/ruby/2.1.5/gems/rest-client-1.8.0/lib/restclient/request.rb:413:in `transmit'
/Users/myron/.gem/ruby/2.1.5/gems/rest-client-1.8.0/lib/restclient/request.rb:176:in `execute'
/Users/myron/.gem/ruby/2.1.5/gems/rest-client-1.8.0/lib/restclient/request.rb:41:in `execute'
/Users/myron/.gem/ruby/2.1.5/gems/coveralls-0.8.1/lib/coveralls/api.rb:23:in `post_json'
/Users/myron/.gem/ruby/2.1.5/gems/coveralls-0.8.1/lib/coveralls/simplecov.rb:72:in `format'
/Users/myron/.gem/ruby/2.1.5/gems/simplecov-0.10.0/lib/simplecov/result.rb:46:in `format!'
/Users/myron/.gem/ruby/2.1.5/gems/simplecov-0.10.0/lib/simplecov/configuration.rb:159:in `block in at_exit'
/Users/myron/.gem/ruby/2.1.5/gems/simplecov-0.10.0/lib/simplecov/defaults.rb:60:in `call'
/Users/myron/.gem/ruby/2.1.5/gems/simplecov-0.10.0/lib/simplecov/defaults.rb:60:in `block in <top (required)>'
{"message":"Couldn't find a repository matching this job.","error":true}

works with the following master checkouts:

Nothing has changed in rspec-core (where I believe the bug relies) that is related to this since 3.3.0 was released. Here's the diff:

v3.3.0...master

The fetch_or_store method call originated in #1858 but it should only ever be sent to a RSpec::Core::MemoizedHelpers::ThreadsafeMemoized or a RSpec::Core::MemoizedHelpers::NonThreadsafeMemoized, not to a hash.

@myronmarston
Copy link
Member

I just noticed that the travis failure you linked to was running 1.9.3. I tried against that version and I still can't reproduce.

@e2
Copy link
Contributor Author

e2 commented Jun 17, 2015

Sorry - I should've tried using a docker container from the start. I added a bogus change to trigger the failure on this branch: https://github.com/guard/listen/tree/trigger_fetch_or_store_problem (this change: guard/listen@4ccf665).

If you can't reproduce that locally, here's how to reproduce an environment with the failure:

  1. docker run -i -t e2dk/rvm_user_install /bin/bash -l
  2. git clone -b trigger_fetch_or_store_problem https://github.com/guard/listen
  3. cd listen && bundle install && CI=true rspec spec/acceptance/tcp_spec.rb:40

If that fails, give me some pointers on how what I should look out for to check/inspect/debug - I can bisect, but I'm not sure if that will help if this is a race condition of some sort.

My system: AMD64, 4 cores, Ubuntu 15.04, ruby 2.2.1p85 (through RVM), gems:

rspec (3.3.0)
rspec-core (3.3.0)
rspec-expectations (3.3.0)
rspec-mocks (3.3.0)
rspec-retry (0.4.0)
rspec-support (3.3.0)

@myronmarston
Copy link
Member

Having never used docker....is brew install docker sufficient to get docker running so I can follow your repro steps?

@e2
Copy link
Contributor Author

e2 commented Jun 17, 2015

Well, having never used OSX before ... (to be honest, I used it once, lol).

It should be sufficient - docker runs a virtual machine with a micro os under Windows and OSX - and most stuff should work out of the box after installing it. docker run ... should be sufficient after installing.

@e2
Copy link
Contributor Author

e2 commented Jun 17, 2015

My docker image is minimal (vim-tiny as editor, bash) and runs as user, so if you want to install anything extra as root, you'll need to instead do:

docker run -i -t -u root e2dk/rvm_user_install /bin/bash -l # runs as root
apt-get install vim-nox # or whatever editors/tools you like/need
su guest # to use rvm as user, install gems, etc.

If you have any strange problems or inconveniences, let me know if I can help and get them out of your way.

@JonRowe
Copy link
Member

JonRowe commented Jun 17, 2015

Sounds like mixed versions of RSpec... Possibly through guard holding old code?

@e2
Copy link
Contributor Author

e2 commented Jun 17, 2015

@JonRowe - not the issue: I listed the versions of RSpec used above. Only happens on currently released latest versions:

rspec (3.3.0)
rspec-core (3.3.0)
rspec-expectations (3.3.0)
rspec-mocks (3.3.0)
rspec-retry (0.4.0)
rspec-support (3.3.0)

There's no lock on any RSpec version, Gemfile.lock is not in version control, etc. - and the docker image gets it's gems directly from rubygems at the latest available versions, so it's proof there's nothing specific to my setup, or Travis having old cached files/version.

@JonRowe
Copy link
Member

JonRowe commented Jun 18, 2015

Have you actually verified that only those versions of rspec are installed? Because without a lock file you have no guarantee which versions are installed (Gemfile.lock should be in version control for apps)

@JonRowe
Copy link
Member

JonRowe commented Jun 18, 2015

The alternative is something is monkey patching RSpec. That variable used to be a hash in a previous version of RSpec thats why I'm asking.

@e2
Copy link
Contributor Author

e2 commented Jun 18, 2015

Have you actually verified that only those versions of rspec are installed?

Yes - install the docker container for yourself and check. It's basically my environment packaged in a 500MB VM for you to verify and debug. It could be related to rspec-retry, but this is about debugging RSpec internals.

@JonRowe JonRowe closed this as completed Jun 18, 2015
@JonRowe
Copy link
Member

JonRowe commented Jun 18, 2015

I've found the issue, rspec-retry monkey patches over our variable.

@JonRowe
Copy link
Member

JonRowe commented Jun 18, 2015

@e2
Copy link
Contributor Author

e2 commented Jun 23, 2015

Awesome work @JonRowe - thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants