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

"str".freeze optimization sporadically produces a different object #5070

Closed
headius opened this issue Mar 1, 2018 · 2 comments · Fixed by #5811
Closed

"str".freeze optimization sporadically produces a different object #5070

headius opened this issue Mar 1, 2018 · 2 comments · Fixed by #5811
Milestone

Comments

@headius
Copy link
Member

headius commented Mar 1, 2018

There's a newly-modified spec that tests "abc".freeze.equal?("abc".freeze) and it appears to be intermittently failing. It appears to fail consistently on Travis.

[The spec] looks like this:

  it "produces the same object whenever called on an instance of a literal in the source" do
    "abc".freeze.should equal "abc".freeze
  end

And fails like this:

     [exec] 1)
     [exec] String#freeze produces the same object whenever called on an instance of a literal in the source FAILED
     [exec] Expected "abc"
     [exec]  to be identical to "abc"
     [exec] 
     [exec] /home/travis/build/jruby/jruby/spec/ruby/core/string/freeze_spec.rb:6:in `block in (root)'
     [exec] org/jruby/RubyBasicObject.java:2595:in `instance_eval'
     [exec] org/jruby/RubyEnumerable.java:1704:in `all?'
     [exec] org/jruby/RubyArray.java:1777:in `each'
     [exec] /home/travis/build/jruby/jruby/spec/ruby/core/string/freeze_spec.rb:3:in `<main>'
     [exec] org/jruby/RubyKernel.java:987:in `load'
     [exec] org/jruby/RubyBasicObject.java:2595:in `instance_eval'
     [exec] org/jruby/RubyArray.java:1777:in `each'

See #4970 for a related issue we believed we fixed in 9.1.16.

@headius headius added this to the JRuby 9.2.0.0 milestone Mar 1, 2018
headius added a commit that referenced this issue Mar 1, 2018

Verified

This commit was signed with the committer’s verified signature.
headius Charles Oliver Nutter
@enebo enebo modified the milestones: JRuby 9.2.0.0, JRuby 9.2.1.0 May 24, 2018
@headius headius modified the milestones: JRuby 9.2.1.0, JRuby 9.2.2.0 Oct 26, 2018
@enebo enebo modified the milestones: JRuby 9.2.5.0, JRuby 9.2.6.0 Dec 6, 2018
@enebo enebo modified the milestones: JRuby 9.2.6.0, JRuby 9.2.7.0 Dec 19, 2018
@enebo enebo modified the milestones: JRuby 9.2.7.0, JRuby 9.2.8.0 Jan 9, 2019
@headius
Copy link
Member Author

headius commented Aug 1, 2019

I think this was due to the entire rubyspec suite running with --debug which turns on --debug=frozen-string-literal, causing all frozen strings to be new instances for debugging. I'll remove the tag and ensure it's passing on travis.

@headius
Copy link
Member Author

headius commented Aug 1, 2019

FYI --debug is now relegated to the slow rubyspec run, which does not include the String#freeze specs.

headius added a commit that referenced this issue Aug 1, 2019
This was likely failing because we ran the full RubySpec suite
with --debug when run through rake. This turned on frozen string
debugging, which disabled the deduplication this spec tests.

Fixes #5070.
Adithya-copart pushed a commit to Adithya-copart/jruby that referenced this issue Aug 25, 2019
This was likely failing because we ran the full RubySpec suite
with --debug when run through rake. This turned on frozen string
debugging, which disabled the deduplication this spec tests.

Fixes jruby#5070.
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

Successfully merging a pull request may close this issue.

2 participants