unable to get value of object's fields in RubyMine debugger #2301
Comments
|
@headius it would be nice to get your thoughts about the problem |
|
Has this ever worked in JRuby? Why aren't you using instance_variable_get? I suppose it could be a bug, but this is an incredibly weird way to get instance variables out of an object. |
|
Honestly, I do not know I've not seen this working, but I only tested with modern jruby while the code was written long time ago. If you know a better way to get field's value from an object I'm ok to change ruby-debug-base. |
|
You should be able to use instance_variables and instance_variable_get on most objects (perhaps not BasicObject) to introspect instance variables. I'm guessing the eval form is done to avoid cases where those methods are unavailable or redefined (e.g. a blank slate object). I think there's still a bug here, though, since it seems like at least one of these eval forms should have been able to see the @test variable. |
|
Ok, a slightly reduced case that should work, but it shows that when we create a binding inside instance_eval it does not get the proper "self". class Foo
attr_accessor :test
end
foo = Foo.new
foo.test = 'visible?'
puts foo.test
p eval("self", foo.instance_eval("binding")) # => "main"
p eval("@test", foo.instance_eval("binding")) # => "nil" |
|
I have a likely fix that basically just uses the instance_eval "self" as the frame "self" when pushing a frame in preExecuteUnder. It's a little scary to change, though. |
|
Incidentally I am also posing removing that method altogether on master :) We are pushing 2 scopes in IR one from preExecuteUnder and one by IR interpreter... |
|
@enebo that sounds fine too. I'm going to push my change to a test branch and see how Travis test runs handle it before doing something similar for release branches. |
This is a bit of a scary change, so pushing to a test branch for now.
|
Pushed my change to branch "test-instance_eval-self-fix-2301" and the travis run is here: https://travis-ci.org/jruby/jruby/builds/44131805. If it passes, this may be an ok fix for both branches, but I will also defer to @enebo since he's working on eval right now on master. |
|
I got very excited about this this morning, and upgraded jruby-1.7.17 to jruby-1.7.18. Sadly, it only fixes part of the problem. Class variables are shown properly, but instance variables are not. :-( I'll raise it again with the rubymine folks. @headius: Thanks for all your efforts, and have a good Christmas. |
|
@mount986 I have added a comment here: https://youtrack.jetbrains.com/issue/RUBY-15864 I don't know if the current fix is enough for @os97673 and his colleagues to be able to fix the RubyMine debugger. |
|
Fix applied in b5b7305 does not appear to have been enough. Can you show the current failing test case? I'm not sure what we don't do at this point. |
|
@headius both the test you provided and my original tests still work the same way as before :( |
|
Any chance to get the problem fixed? |
|
I think we have this working correctly in JRuby 9k, but 1.7.x still has the wrong output. |
|
Hopefully it is now fixed to everyone's satisfaction. @os97673 Please try out a head or snapshot build with the latest fix and let us know if it's working properly. |
|
I'm trying out jruby-head, but from the install output, this branch is the new 9.0.0.0 branch. Is there a branch for the planned 1.7.20? The reason I ask is that when I use the 9.0.0.0.pre1 branch, I get errors in my tests, probably due to some difference in the postgresql adapter. It objects to doing inserts specifying nil values for columns with default values. This seems to work fine in 1.7.19, but not in 9.0.0.0.pre1. I'll see if I can track down the cause a bit more. For now, I'm trying out jruby-head for the current bug. |
|
Hi @ninkibah ! The branch for the upcoming 1.7.20 release is "jruby-1_7". |
|
@headius the original problem is fixed. |
|
Re-added DynamicScope.getNextCapturedScope to not break ruby-debug-ide on master to address unrelated error @os97673 reported. jruby-1_7 still reports wrong output so I am leaving this issue open since it is fixed on master but not on jruby-1_7. |
|
@ninkibah Sorry to hear you had issues with your app on 9k.pre1. If you still have those issues on pre2 we REALLY want to know about them. @os97673 I think this should be working correctly now in 1.7.20 and @enebo's fix for master should be in 9k.pre2. Can you please confirm things are working with 9k.pre2 and a head build of jruby-1_7 branch? |
|
Optimistically closing this because the spec passes and the 9k fix was cherry-picked over to 1.7. |
|
@headius I might try out 9k pre2 this weekend, as we have a bank holiday on Monday! When is 1.7.20 coming out? |
I've tried 9k.pre2 and everything works ok there. |
|
tried jruby-1_7 and the test works correctly. |
|
@os97673 Thanks for the confirmation :-) |
|
@headius just FYI; this patch turned out to be a pretty huge improvement in memory usage for us :) Prior to the patch the objects that were referenced by the Frame.self field included a lot of unnecessary scope, and thus if we had other code that held references to those, it meant that there was a huge amount of memory that could not be GC'd. With this patch the retained size for each one of the objects we created via a call to instance_eval went down from 7MB to less than 1kb. :) Granted this probably has more to do with what our code is doing with these evals than what JRuby is, but thought you might be interested in that data point. |
Originally filed agains RubyMine (https://youtrack.jetbrains.com/issue/RUBY-15864)
Users basically unable to see value of object's fields.
Here is a simple example which shows how we (ruby-debug-base) try to get value of fields.
It looks like a bug for me, but if it is not please suggest a way to implement similar functionality for jruby.
The text was updated successfully, but these errors were encountered: