JRuby

self is wrong in set_trace_func when raising NoMethodErrors

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Trivial Trivial
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: JRuby 1.7.0.RC1
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

set_trace_func(proc{ |event, file, line, method, binding, klass|
  puts binding.eval("[self, s]").inspect if event == "raise"
})

def hello
  s = "snorkle"
  s.desnrok
end

hello
# output:
# ["snorkle", "snorkle"]
# NoMethodError: undefined method `desnrok' for "snorkle":String
#   hello at a.rb:7
#  (root) at a.rb +10

Both 's' and 'self' are "snorkle" — 'self' in this case should be main.

I'm bringing this up because I encountered the same problem when calling ThreadContext#currentBinding() in interception: https://github.com/ConradIrwin/interception/blob/master/ext/org/pryrepl/InterceptionEventHook.java

In this case the problem could be fixed by using ThreadContext#previousBinding(), but I'm unable to decide at runtime which one should be used (always using previousBinding() causes other cases to fail).

The promising looking ThreadContext#getCurrentRubyFrame() seems to not help as it is the same as ThreadContext#currentFrame().

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

Weird.

Show
Charles Oliver Nutter added a comment - Weird.
Hide
Permalink
Charles Oliver Nutter added a comment -

Ok, I believe the problem here is that our default method_missing implementations are framed; as a result, the current binding is actually the binding of method_missing, which runs with self="snorkle". The s="snorkle is as expected because default method_missing does not get its own scope, and the binding gets the proper caller scope.

I also don't see any reason why we need to frame method_missing anymore. Testing that fix.

Show
Charles Oliver Nutter added a comment - Ok, I believe the problem here is that our default method_missing implementations are framed; as a result, the current binding is actually the binding of method_missing, which runs with self="snorkle". The s="snorkle is as expected because default method_missing does not get its own scope, and the binding gets the proper caller scope. I also don't see any reason why we need to frame method_missing anymore. Testing that fix.
Hide
Permalink
Charles Oliver Nutter added a comment - 
commit 4246d96f63155aeb70694a9a0ace0eeb2c936065
Author: Charles Oliver Nutter <headius@headius.com>
Date:   Tue Aug 21 22:27:47 2012 -0500

    Fix JRUBY-6832
    
    self is wrong in set_trace_func when raising NoMethodErrors
    
    The default method_missing implementations still were being
    framed, since they used to need that to get the name of the method
    being called. However, at some point they just started to use the
    name being passed through the call chain, which meant the frame
    was unnecessary. The bug was caused by the fact that the binding's
    self also comes from the frame, which in method_missing would be
    the object against which the missing method was being called. That
    caused both "self" and "s" in the bug report to point at the
    String in question, since "self" came from m_m's frame and "s"
    came from the caller's scopes (m_m did not get its own scope).
    Removing the framing from m_m fixed the issue and did not
    introduce others (since that frame was not actually being used
    anymore).

:100644 100644 19877cb... dc354fd... M	src/org/jruby/RubyKernel.java
:100644 100644 ba60bbc... a6835db... M	test/tracing/test_trace_func.rb
Show
Charles Oliver Nutter added a comment - commit 4246d96f63155aeb70694a9a0ace0eeb2c936065 Author: Charles Oliver Nutter <headius@headius.com> Date: Tue Aug 21 22:27:47 2012 -0500 Fix JRUBY-6832 self is wrong in set_trace_func when raising NoMethodErrors The default method_missing implementations still were being framed, since they used to need that to get the name of the method being called. However, at some point they just started to use the name being passed through the call chain, which meant the frame was unnecessary. The bug was caused by the fact that the binding's self also comes from the frame, which in method_missing would be the object against which the missing method was being called. That caused both "self" and "s" in the bug report to point at the String in question, since "self" came from m_m's frame and "s" came from the caller's scopes (m_m did not get its own scope). Removing the framing from m_m fixed the issue and did not introduce others (since that frame was not actually being used anymore). :100644 100644 19877cb... dc354fd... M src/org/jruby/RubyKernel.java :100644 100644 ba60bbc... a6835db... M test/tracing/test_trace_func.rb

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Conrad Irwin
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: