Hello,
eversince I switched to Rails 3 I keep getting following error:
RuntimeError: can’t modify frozen hash
This is the affected line:
self.target.save
target is a polymorphic relation and never caused any problems before.
I added an output for the frozen hash to get the ID of it and fired up
the console to get some more info out of it:
ruby-1.9.2-p0 > b = Building.find(1008631573)
And nothing happens. It stays there until I abort it.
Does anyone know how I could find the source of this problem?
Thanks
Your code freezing on the self.target.save line, made me think you had a
before_save filter. The Building.find(1008631573) freezing makes me
think that there’s something un-vanilla about your rails install.
Try removing all plugins, gems and any initializers that you have and
see if the problem goes away. If that doesn’t work, create a fresh rails
project and add your model code and see if the new project has any
problems.
Does your model have any methods in it that are declared in AR::Base ?
Luke
Luke C. wrote:
Your code freezing on the self.target.save line, made me think you had a
before_save filter. The Building.find(1008631573) freezing makes me
think that there’s something un-vanilla about your rails install.
Try removing all plugins, gems and any initializers that you have and
see if the problem goes away. If that doesn’t work, create a fresh rails
project and add your model code and see if the new project has any
problems.
Does your model have any methods in it that are declared in AR::Base ?
Luke
I ran the tests some more times and I got a new frozen hash error for
some reason which is now on this line. It’s the same object: Building:
self.target.condition
RuntimeError: can’t modify frozen hash
/usr/local/rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/attribute_methods/write.rb:24:in
[]=' /usr/local/rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/attribute_methods/write.rb:24:inwrite_attribute’
/usr/local/rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/attribute_methods/dirty.rb:61:in
write_attribute' /usr/local/rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/attribute_methods/write.rb:13:incondition=’
/usr/local/rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/associations/association_proxy.rb:218:in
method_missing' /var/www/rails_app/app/models/activity.rb:153:inexecute’
The model itself is not using any specific gems but has 3 belongs_to’s
and and 4 has_many’s. Therefore I would kinda need to copy half the
application to the newly created project…
What I also ran into is this error: ActiveRecord::StatementInvalid:
Mysql::LockWaitTimeout: Lock wait timeout exceeded; try restarting
transaction. Got it when I ran the same test but on a completely
different line.
Can I somehow check what froze the hash and locked the other one? I
never had any of these problems in Rails 2.
On Oct 3, 11:01 am, Heinz S. [email protected] wrote:
Luke C. wrote:
The model itself is not using any specific gems but has 3 belongs_to’s
and and 4 has_many’s. Therefore I would kinda need to copy half the
application to the newly created project…
An alternative approach is to take your existing app and to remove
stuff until things work again. One thing that appeared suspicious to
me is the association called target - association proxies have a
method called target, so while I wouldn’t expect foo.target to cause a
problem, some_association.foo.target might.
Fred
Alright, renaming it didn’t help but I think I need to make the whole
thing a bit more clear.
self is an activity which is on a building in the case where it fails.
I’ve got about 6 different activities and all work but one. So my test
executes this activities 100 times to see the success rate etc.
So the other 5 activities who are pretty much the same work just fine
and now I put a counter to see when it fails.
It failed 37th, 49th and 50th time so it doesn’t really happen at one
specific time. Who can this frozen hash thing happen so radomly and only
in that activity?
When I load and modify the ‘activity_target’ in the console I can modify
and update it as I wish (which also works 37-50 times in the test
though).
I’m not sure what to make of the sporadic failures. Changing the method
names didn’t work, but are there any columns in the table that could be
in conflict ? Those column names will cause rails to generate a number
of methods for the model.
What does this line say (or whatever line number it is after you’ve
modified your model?
/var/www/rails_app/app/models/activity.rb:153
It would be helpful to see any other pertinent code.
Luke
Frederick C. wrote:
An alternative approach is to take your existing app and to remove
stuff until things work again. One thing that appeared suspicious to
me is the association called target - association proxies have a
method called target, so while I wouldn’t expect foo.target to cause a
problem, some_association.foo.target might.
Fred
That’s a good point. I’ll rename it and see what happens.
Frederick C. wrote:
On Oct 3, 11:01�am, Heinz S. [email protected] wrote:
Luke C. wrote:
The model itself is not using any specific gems but has 3 belongs_to’s
and and 4 has_many’s. Therefore I would kinda need to copy half the
application to the newly created project…
An alternative approach is to take your existing app and to remove
stuff until things work again. One thing that appeared suspicious to
me is the association called target - association proxies have a
method called target, so while I wouldn’t expect foo.target to cause a
problem, some_association.foo.target might.
If you are using Git, I highly recommend git bisect to figure out where
a problem was introduced.
Fred
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]