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

Thread::Backtrace::Location#base_label for blocks differs from MRI #5162

Closed
ivoanjo opened this issue May 10, 2018 · 4 comments
Closed

Thread::Backtrace::Location#base_label for blocks differs from MRI #5162

ivoanjo opened this issue May 10, 2018 · 4 comments
Milestone

Comments

@ivoanjo
Copy link
Contributor

ivoanjo commented May 10, 2018

Hello again!

I'm using Thread#backtrace_locations and noticed several differences between MRI and JRuby.

I'll report them separately because they may have different fixes, but feel free to mark any as duplicate if it makes sense to do so.


Environment

  • JRuby: jruby 9.1.17.0 (2.3.3) 2018-04-20 d8b1ff9 Java HotSpot(TM) 64-Bit Server VM 25.171-b11 on 1.8.0_171-b11 +jit [linux-x86_64]
  • Kernel: Linux u186024434db159d25c92 4.13.0-39-generic #44~16.04.1-Ubuntu SMP Thu Apr 5 16:43:10 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
  • Distro: Ubuntu 16.04.4 LTS

Expected Behavior

When looking at a Thread::Backtrace::Location, MRI provides both #base_label and #label.

For most methods, these are exactly the same, but for blocks it allows the caller to get the name of the method separate from the "block in" text without resorting to parsing the result.

Testcase:

puts RUBY_DESCRIPTION

def test
  [:test].map do
    location = Thread.current.backtrace_locations[1]
    puts "#base_label '#{location.base_label}', #label '#{location.label}'"
  end
end

test

Output on MRI:

ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
#base_label 'test', #label 'block in test'

Actual Behavior

JRuby does not make such a distinction, and so base_label effectively becomes an alias of label:

jruby 9.1.17.0 (2.3.3) 2018-04-20 d8b1ff9 Java HotSpot(TM) 64-Bit Server VM 25.171-b11 on 1.8.0_171-b11 +jit [linux-x86_64]
#base_label 'block in test', #label 'block in test'

If it would be helpful I can also submit a testcase to RubySpec.

@headius
Copy link
Member

headius commented May 14, 2018

A test case would be great!

@headius
Copy link
Member

headius commented May 14, 2018

Oh I submitted too soon. Are you planning to try to fix these issues, or shall we? If it's up to us, it's unlikely to happen before the 9.2 release (next Mondayish). Even if you do it, it's probably going to be a 9.2.1 thing.

@headius headius added this to the JRuby 9.2.1.0 milestone May 14, 2018
@ivoanjo
Copy link
Contributor Author

ivoanjo commented May 15, 2018

Thanks for the answer, I'll submit a PR with a test case asap then.

As for the fix itself I wasn't planning on taking a stab as I don't think I'll have enough time to pick it up soon-ish.

@headius
Copy link
Member

headius commented May 15, 2018

Ok thanks. I'll leave these marked for 9.2.1 then. May not be too difficult to fix if we can sort out a better way to do the "block in" thing.

enebo added a commit that referenced this issue Jun 14, 2018
…s from MRI.

This fix is not quite what I would have liked but I think the other issue we
will need to consider at some point is that this data is not m17n safe.  So
when we decide to fix that we will need to mangle differently and probably will
be able to clean up this a bit.
@enebo enebo closed this as completed in 9bfd29f Jun 14, 2018
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

2 participants