-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
Bundler fails under +indy (claims gems listed more than once) #3950
Comments
This is likely the same issue I posted to bundler about a month ago |
Success! I have reproduced this on my machine. |
It seems like under indy, there's a bogus specification in Bundler:
I'm trying to figure out where these are constructed. |
Whew, finally got it. Seems to be a problem with reified instance variables. For some reason, the attr_accessor-defined variables in Gem::Specification are not getting set or read properly. If you pass I'll get it patched up for 9.1.3.0. |
Ok, I figured out the problem. As of 9.1.0.0 we started "reifying" up to ten instance variables per Ruby class, allocating specialized objects with up to ten fields. This reduces memory size for objects with under ten variables, since they no longer need a separate growable array to hold values. The bug is that when a parent class reifies its variables, the child class should do so as well. In this case, This manifests when building up the I have a fix I am testing locally that detects whether a parent class was itself reifiable, and if so it sets the child to also be reifiable. This allows all classes in the system to have their own layout of instance variables without stepping on super or subclasses. This bug is good justification for us to finally get JIT + indy runs into CI. |
I have a reproduction, finally! class Foo
attr_accessor :name
def initialize(name)
self.name = name
end
def full_name
name.to_s + 'baz'
end
end
4.times {
p Foo.new('foo').full_name
}
puts
class Bar < Foo
def initialize(name)
@name = name
end
end
4.times {
p Bar.new('foo').full_name
} The output follows:
The Foo objects work properly every time, setting and getting the name value. The Bar objects, on the other hand, start out ok and then starts to fail. I haven't worked out the sequence here, but in most cases the first encounter with a variable or call site will use the slow logic, and subsequent encounters will use fast logic. In this case it seems to take a couple iterations for everything to get bound to the fast logic. I will try to turn this into a test along with my fix. |
I've pushed my fix and test to master, but we still need to get |
Environment
Expected Behavior
To work identically to the (not at all problematic) behavior without +indy
Actual Behavior
Dumps the following:
The text was updated successfully, but these errors were encountered: