4
false
2008-11-06T21:36:17+00:00
28420
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
647
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking its children, just because it lost interest
2009-10-22T05:13:29+01:00
73743
Sai Emrys
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
I diagnosed the following issue as part of [ref1], but it has since come
up again as part of [ref2].
This new ticket is to discuss it in isolation.
## The issue:
Whenever an AR::Base instance is persisted between requests with
cache_classes disabled, Dispatcher#reset_application! will go through
all its subclasses and remove all its instance methods and instance
variables (those on the instance of Class not on instances of
AR::Base, it's all very confusing!).
This was intended to fix a memory leak [ref3], and had a test associated
with it. The test is now long gone, and my efforts at re-adding it
failed because I never got it to pass, with or without the class
stripping.
## The effect:
The example app by David Rice [ref4] will explode with error [ref5] after 2
page loads.
This app saves an AR model to a constant at startup... then expects it
to work after a reload!.
After a reload the model gets very confused, as its class has all its
class_inheritable_attributes stripped.
It expects an array to be dangling off the end of
`#skip_time_zone_conversion_for_attributes`, but instead it finds nil.
This sucks.
## What should happen (IMHO):
Removing the references to classes in @@subclasses should be enough to
allow garbage collection to do the good stuff when the relevant
constants (that refer to the classes) are removed.
This way, any objects that are still referencing those classes (you
know, like when they are an instance of them), can still operate
without unnecessary loss of organs.
## The patch:
The attached patch, rebased especially for the occasion, stops AR from
behaving in this odd way, and seems to pass the existing test pack.
## The questions:
Does anyone have a good reason why these lines should stay?
Can anyone create a failing test case? (preferably one that passes
before the patch is applied ;)
Does anyone remember why the code is there?
Thanks in advance for any thoughts / input / other.
- Tom
p.s.
I had to revert my local rails back to 55707da1a1481, as 8adb79b9b598
onwards clashed with my MySQL.
Tests passed at that point though.
### References
* [ref1] http://rails.lighthouseapp.com/projects/8994/tickets/785
* [ref2] http://rails.lighthouseapp.com/projects/8994/tickets/1290
* [ref3] http://github.com/rails/rails/commit/e7f61eab56d8a628cc605e5fa1e9055c4df852c7
* [ref4] http://rails.lighthouseapp.com/attachments/59425/lighthouse-ticket-1290.zip
* [ref5] http://pastie.org/308884
I diagnosed the following issue as part of [ref1], but it has since come
up again as part of [ref2].
This new ticket is to discuss it in isolation.
## The issue:
Whenever an AR::Base instance is persisted between requests with
cache_classes disabled, Dispatcher#reset_application! will go through
all its subclasses and remove all its instance methods and instance
variables (those on the instance of Class not on instances of
AR::Base, it's all very confusing!).
This was intended to fix a memory leak [ref3], and had a test associated
with it. The test is now long gone, and my efforts at re-adding it
failed because I never got it to pass, with or without the class
stripping.
## The effect:
The example app by David Rice [ref4] will explode with error [ref5] after 2
page loads.
This app saves an AR model to a constant at startup... then expects it
to work after a reload!.
After a reload the model gets very confused, as its class has all its
class_inheritable_attributes stripped.
It expects an array to be dangling off the end of
`#skip_time_zone_conversion_for_attributes`, but instead it finds nil.
This sucks.
## What should happen (IMHO):
Removing the references to classes in @@subclasses should be enough to
allow garbage collection to do the good stuff when the relevant
constants (that refer to the classes) are removed.
This way, any objects that are still referencing those classes (you
know, like when they are an instance of them), can still operate
without unnecessary loss of organs.
## The patch:
The attached patch, rebased especially for the occasion, stops AR from
behaving in this odd way, and seems to pass the existing test pack.
## The questions:
Does anyone have a good reason why these lines should stay?
Can anyone create a failing test case? (preferably one that passes
before the patch is applied ;)
Does anyone remember why the code is there?
Thanks in advance for any thoughts / input / other.
- Tom
p.s.
I had to revert my local rails back to 55707da1a1481, as 8adb79b9b598
onwards clashed with my MySQL.
Tests passed at that point though.
### References
* [ref1] http://rails.lighthouseapp.com/projects/8994/tickets/785
* [ref2] http://rails.lighthouseapp.com/projects/8994/tickets/1290
* [ref3] http://github.com/rails/rails/commit/e7f61eab56d8a628cc605e5fa1e9055c4df852c7
* [ref4] http://rails.lighthouseapp.com/attachments/59425/lighthouse-ticket-1290.zip
* [ref5] http://pastie.org/308884
<div><p>I diagnosed the following issue as part of [ref1], but it has
since come up again as part of [ref2].</p>
<p>This new ticket is to discuss it in isolation.</p>
<h2>The issue:</h2>
<p>Whenever an AR::Base instance is persisted between requests with
cache_classes disabled, Dispatcher#reset_application! will go
through all its subclasses and remove all its instance methods and
instance variables (those on the instance of Class not on instances
of AR::Base, it's all very confusing!).</p>
<p>This was intended to fix a memory leak [ref3], and had a test
associated with it. The test is now long gone, and my efforts at
re-adding it failed because I never got it to pass, with or without
the class stripping.</p>
<h2>The effect:</h2>
<p>The example app by David Rice [ref4] will explode with error
[ref5] after 2 page loads.</p>
<p>This app saves an AR model to a constant at startup... then
expects it to work after a reload!.</p>
<p>After a reload the model gets very confused, as its class has
all its class_inheritable_attributes stripped.</p>
<p>It expects an array to be dangling off the end of
<code>#skip_time_zone_conversion_for_attributes</code>, but instead
it finds nil.</p>
<p>This sucks.</p>
<h2>What should happen (IMHO):</h2>
<p>Removing the references to classes in @@subclasses should be
enough to allow garbage collection to do the good stuff when the
relevant constants (that refer to the classes) are removed.</p>
<p>This way, any objects that are still referencing those classes
(you know, like when they are an instance of them), can still
operate without unnecessary loss of organs.</p>
<h2>The patch:</h2>
<p>The attached patch, rebased especially for the occasion, stops
AR from behaving in this odd way, and seems to pass the existing
test pack.</p>
<h2>The questions:</h2>
<p>Does anyone have a good reason why these lines should stay?</p>
<p>Can anyone create a failing test case? (preferably one that
passes before the patch is applied ;)</p>
<p>Does anyone remember why the code is there?</p>
<p>Thanks in advance for any thoughts / input / other.</p>
<ul>
<li>Tom</li>
</ul>
<p>p.s.</p>
<p>I had to revert my local rails back to 55707da1a1481, as
8adb79b9b598 onwards clashed with my MySQL.</p>
<p>Tests passed at that point though.</p>
<h3>References</h3>
<ul>
<li>[ref1] <a href="http://rails.lighthouseapp.com/projects/8994/tickets/785">http://rails.lighthouseapp.com/p...</a></li>
<li>[ref2] <a href="http://rails.lighthouseapp.com/projects/8994/tickets/1290">http://rails.lighthouseapp.com/p...</a></li>
<li>[ref3] <a href="http://github.com/rails/rails/commit/e7f61eab56d8a628cc605e5fa1e9055c4df852c7">
http://github.com/rails/rails/co...</a></li>
<li>[ref4] <a href="http://rails.lighthouseapp.com/attachments/59425/lighthouse-ticket-1290.zip">
http://rails.lighthouseapp.com/a...</a></li>
<li>[ref5] <a href="http://pastie.org/308884">http://pastie.org/308884</a></li>
</ul></div>
0
I diagnosed the following issue as part of [ref1], but it has since come
up again as part of [ref2].
This new ticket is to discuss it in isolation.
## The issue:
Whenever an AR::Base instance is persisted between requests with
cache_classes disabled, Dispatcher#reset_application! will go through
all its subclasses and remove all its instance methods and instance
variables (those on the instance of Class not on instances of
AR::Base, it's all very confusing!).
This was intended to fix a memory leak [ref3], and had a test associated
with it. The test is now long gone, and my efforts at re-adding it
failed because I never got it to pass, with or without the class
stripping.
## The effect:
The example app by David Rice [ref4] will explode with error [ref5] after 2
page loads.
This app saves an AR model to a constant at startup... then expects it
to work after a reload!.
After a reload the model gets very confused, as its class has all its
class_inheritable_attributes stripped.
It expects an array to be dangling off the end of
`#skip_time_zone_conversion_for_attributes`, but instead it finds nil.
This sucks.
## What should happen (IMHO):
Removing the references to classes in @@subclasses should be enough to
allow garbage collection to do the good stuff when the relevant
constants (that refer to the classes) are removed.
This way, any objects that are still referencing those classes (you
know, like when they are an instance of them), can still operate
without unnecessary loss of organs.
## The patch:
The attached patch, rebased especially for the occasion, stops AR from
behaving in this odd way, and seems to pass the existing test pack.
## The questions:
Does anyone have a good reason why these lines should stay?
Can anyone create a failing test case? (preferably one that passes
before the patch is applied ;)
Does anyone remember why the code is there?
Thanks in advance for any thoughts / input / other.
### References
* [ref1] http://rails.lighthouseapp.com/projects/8994/tickets/785
* [ref2] http://rails.lighthouseapp.com/projects/8994/tickets/1290
* [ref3] http://github.com/rails/rails/commit/e7f61eab56d8a628cc605e5fa1e9055c4df852c7
* [ref4] http://rails.lighthouseapp.com/attachments/59425/lighthouse-ticket-1290.zip
* [ref5] http://pastie.org/308884
<div><p>I diagnosed the following issue as part of [ref1], but it has
since come up again as part of [ref2].</p>
<p>This new ticket is to discuss it in isolation.</p>
<h2>The issue:</h2>
<p>Whenever an AR::Base instance is persisted between requests with
cache_classes disabled, Dispatcher#reset_application! will go
through all its subclasses and remove all its instance methods and
instance variables (those on the instance of Class not on instances
of AR::Base, it's all very confusing!).</p>
<p>This was intended to fix a memory leak [ref3], and had a test
associated with it. The test is now long gone, and my efforts at
re-adding it failed because I never got it to pass, with or without
the class stripping.</p>
<h2>The effect:</h2>
<p>The example app by David Rice [ref4] will explode with error
[ref5] after 2 page loads.</p>
<p>This app saves an AR model to a constant at startup... then
expects it to work after a reload!.</p>
<p>After a reload the model gets very confused, as its class has
all its class_inheritable_attributes stripped.</p>
<p>It expects an array to be dangling off the end of
<code>#skip_time_zone_conversion_for_attributes</code>, but instead
it finds nil.</p>
<p>This sucks.</p>
<h2>What should happen (IMHO):</h2>
<p>Removing the references to classes in @@subclasses should be
enough to allow garbage collection to do the good stuff when the
relevant constants (that refer to the classes) are removed.</p>
<p>This way, any objects that are still referencing those classes
(you know, like when they are an instance of them), can still
operate without unnecessary loss of organs.</p>
<h2>The patch:</h2>
<p>The attached patch, rebased especially for the occasion, stops
AR from behaving in this odd way, and seems to pass the existing
test pack.</p>
<h2>The questions:</h2>
<p>Does anyone have a good reason why these lines should stay?</p>
<p>Can anyone create a failing test case? (preferably one that
passes before the patch is applied ;)</p>
<p>Does anyone remember why the code is there?</p>
<p>Thanks in advance for any thoughts / input / other.</p>
<h3>References</h3>
<ul>
<li>[ref1] <a href="http://rails.lighthouseapp.com/projects/8994/tickets/785">http://rails.lighthouseapp.com/p...</a></li>
<li>[ref2] <a href="http://rails.lighthouseapp.com/projects/8994/tickets/1290">http://rails.lighthouseapp.com/p...</a></li>
<li>[ref3] <a href="http://github.com/rails/rails/commit/e7f61eab56d8a628cc605e5fa1e9055c4df852c7">
http://github.com/rails/rails/co...</a></li>
<li>[ref4] <a href="http://rails.lighthouseapp.com/attachments/59425/lighthouse-ticket-1290.zip">
http://rails.lighthouseapp.com/a...</a></li>
<li>[ref5] <a href="http://pastie.org/308884">http://pastie.org/308884</a></li>
</ul></div>
false
2008-11-06T21:36:17+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
new
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-06T21:36:49+00:00
28420
Tom Lea
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
141
1
Git blame + git show points those lines as fixing a memory leak in dev mode:
http://github.com/rails/rails/commit/e7f61eab56d8a628cc605e5fa1e9055c4df852c7
I believe we removed that test case, but there's the reason.
Can you confirm that there's no leak in dev mode after applying this patch?
<div><p>Git blame + git show points those lines as fixing a memory leak
in dev mode:</p>
<p><a href="http://github.com/rails/rails/commit/e7f61eab56d8a628cc605e5fa1e9055c4df852c7">
http://github.com/rails/rails/co...</a></p>
<p>I believe we removed that test case, but there's the reason.</p>
<p>Can you confirm that there's no leak in dev mode after applying
this patch?</p></div>
false
2008-11-07T07:39:21+00:00
28420
---
:assigned_user:
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
new
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-07T07:39:24+00:00
141
Michael Koziarski
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Michael Koziarski
141
1
for additional information, the leak previously was caused by the use of define_method() and reloading. The procs used by define_method were held on to indefinitely, despite them not being in use any more.
If this has been fixed in a recent ruby version, then perhaps it's not a big deal. But it was a complete disaster previously.
<div><p>for additional information, the leak previously was caused by
the use of define_method() and reloading. The procs used by
define_method were held on to indefinitely, despite them not being
in use any more.</p>
<p>If this has been fixed in a recent ruby version, then perhaps
it's not a big deal. But it was a complete disaster previously.</p></div>
false
2008-11-07T07:50:48+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
new
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-07T07:50:53+00:00
141
Michael Koziarski
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Michael Koziarski
141
1
Can we make this a 2.2 priority?
<div><p>Can we make this a 2.2 priority?</p></div>
false
2008-11-10T18:42:14+00:00
28420
---
:state: new
:milestone: 9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-10T18:42:17+00:00
424
Joshua Peek
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
Michael Koziarski
141
1
Not with the current implementation.
At present it does not affect anyone running with cache_classes = true, and it leaks (or leaked, no one has done more testing) when the patch is applied.
This is an old issue, and shouldn't block a release, though it'd be nice to have it fixed obviously :)
<div><p>Not with the current implementation.</p>
<p>At present it does not affect anyone running with cache_classes
= true, and it leaks (or leaked, no one has done more testing) when
the patch is applied.</p>
<p>This is an old issue, and shouldn't block a release, though it'd
be nice to have it fixed obviously :)</p></div>
false
2008-11-10T19:56:02+00:00
28420
---
:milestone: 12671
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-10T19:56:08+00:00
141
Michael Koziarski
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Michael Koziarski
141
1
I disagree with Michael Koziarski. This has caused a lot of headaches for a lot of people, and it would be nice if it could be fixed for the next release.
See http://rails.lighthouseapp.com/projects/8994/tickets/785-caching-models-fails-in-development for a long list of complaints. :)
<div><p>I disagree with Michael Koziarski. This has caused a lot of
headaches for a lot of people, and it would be nice if it could be
fixed for the next release.</p>
<p>See <a href="http://rails.lighthouseapp.com/projects/8994/tickets/785-caching-models-fails-in-development">
http://rails.lighthouseapp.com/p...</a> for a long list of
complaints. :)</p></div>
false
2008-11-10T20:22:00+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-10T20:22:02+00:00
17345
Steven Soroka
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Michael Koziarski
141
1
I don't disagree that this is an annoying issue, but the fix in the other ticket to add a marshalling memory store does just as good a job as this patch, without leaking memory.
If you want to help out here, you should test this current patch against the current major versions of ruby (1.8.6, 1.8.7 and whatever debian stable is on) and report back if the code leaks memory in development mode.
<div><p>I don't disagree that this is an annoying issue, but the fix in
the other ticket to add a marshalling memory store does just as
good a job as this patch, without leaking memory.</p>
<p>If you want to help out here, you should test this current patch
against the current major versions of ruby (1.8.6, 1.8.7 and
whatever debian stable is on) and report back if the code leaks
memory in development mode.</p></div>
false
2008-11-10T20:26:37+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-10T20:26:42+00:00
141
Michael Koziarski
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Michael Koziarski
141
1
So I did a little memory profiling, it was a little hacky, so my methods may be bad. If this is so, tell me how to do it better.
I restarted the server each time, and switched branches when appropriate.
## ruby -v
ruby 1.8.6 (2008-03-03 patchlevel 114) [i686-darwin9.4.0]
(I ran the test against 1.8.7, freshly downloaded today, and the result were almost identical, 1.9{,.1} fail to start due to #827 on 1.9 and some other issue that ran over the end of my lunch hour on 1.9.1)
## Test Script
@@@ ruby
#!/usr/bin/env ruby
pid = `ps | grep script/serve[r] | awk '{ print $1 }'`.chomp
puts "Server PID: #{pid}"
url = ARGV.last
puts "URL: #{url}"
puts "Hit enter to go."
$stdin.gets
def get_memory_usage(pid)
`ps -o rss,vsz -p#{pid} | tail -n1`.chomp
end
puts "Initial Memory Usage: #{get_memory_usage(pid)}"
1000.times do
system %Q{wget -O/dev/null -o/dev/null #{url}}
end
puts "Final Memory Usage: #{get_memory_usage(pid)}"
@@@
## Without Patch
@@@
RSS VSZ
Initial Memory Usage: 31568 107692
Final Memory Usage: 43400 128408
Delta: 11832 20716
Initial Memory Usage: 31568 107692
Final Memory Usage: 43460 128628
Delta: 11892 20936
Initial Memory Usage: 31568 107692
Final Memory Usage: 43320 128248
Delta: 11752 20556
Mean Delta: 11825 20736
## With Patch
Initial Memory Usage: 31568 107692
Final Memory Usage: 43584 128308
Delta: 12016 20616
Initial Memory Usage: 31564 107692
Final Memory Usage: 43656 128468
Delta: 12092 20776
Initial Memory Usage: 31612 107736
Final Memory Usage: 43644 128356
Delta: 12032 20620
Mean Delta: 12046 20671
@@@
## Conclusion
So that's a 221k difference over 1000 requests, or an additional 226bytes per request leakage in development, no change in production. This is likely to be more on more complex apps, although I have not had time to do any more in depth testing.
IMHO fixing leakage in this specific way in development mode is kind of pointless, given that the exiting leakage by far out weighs it.
Or taken another way, if the inverse of the patch were proposed, I would object to it, as it would cause the issues we are seeing now.
Opinions please?
<div><p>So I did a little memory profiling, it was a little hacky, so my
methods may be bad. If this is so, tell me how to do it better.</p>
<p>I restarted the server each time, and switched branches when
appropriate.</p>
<h2>ruby -v</h2>
<p>ruby 1.8.6 (2008-03-03 patchlevel 114) [i686-darwin9.4.0]</p>
<p>(I ran the test against 1.8.7, freshly downloaded today, and the
result were almost identical, 1.9{,.1} fail to start due to
<a href="/projects/8994/tickets/827" title="Ticket #827">#827</a>
on 1.9 and some other issue that ran over the end of my lunch hour
on 1.9.1)</p>
<h2>Test Script</h2>
<pre><code class="ruby">
#!/usr/bin/env ruby
pid = `ps | grep script/serve[r] | awk '{ print $1 }'`.chomp
puts "Server PID: #{pid}"
url = ARGV.last
puts "URL: #{url}"
puts "Hit enter to go."
$stdin.gets
def get_memory_usage(pid)
`ps -o rss,vsz -p#{pid} | tail -n1`.chomp
end
puts "Initial Memory Usage: #{get_memory_usage(pid)}"
1000.times do
system %Q{wget -O/dev/null -o/dev/null #{url}}
end
puts "Final Memory Usage: #{get_memory_usage(pid)}"
</code></pre>
<h2>Without Patch</h2>
<pre><code>
RSS VSZ
Initial Memory Usage: 31568 107692
Final Memory Usage: 43400 128408
Delta: 11832 20716
Initial Memory Usage: 31568 107692
Final Memory Usage: 43460 128628
Delta: 11892 20936
Initial Memory Usage: 31568 107692
Final Memory Usage: 43320 128248
Delta: 11752 20556
Mean Delta: 11825 20736
## With Patch
Initial Memory Usage: 31568 107692
Final Memory Usage: 43584 128308
Delta: 12016 20616
Initial Memory Usage: 31564 107692
Final Memory Usage: 43656 128468
Delta: 12092 20776
Initial Memory Usage: 31612 107736
Final Memory Usage: 43644 128356
Delta: 12032 20620
Mean Delta: 12046 20671
</code></pre>
<h2>Conclusion</h2>
<p>So that's a 221k difference over 1000 requests, or an additional
226bytes per request leakage in development, no change in
production. This is likely to be more on more complex apps,
although I have not had time to do any more in depth testing.</p>
<p>IMHO fixing leakage in this specific way in development mode is
kind of pointless, given that the exiting leakage by far out weighs
it.</p>
<p>Or taken another way, if the inverse of the patch were proposed,
I would object to it, as it would cause the issues we are seeing
now.</p>
<p>Opinions please?</p></div>
false
2008-11-12T19:24:10+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-12T19:24:15+00:00
28420
Tom Lea
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Michael Koziarski
85
1
Moving to 2.2 so we can make a final call on this.
Jeremy, You've done a lot of our memory profiling lately, what's your take?
<div><p>Moving to 2.2 so we can make a final call on this.</p>
<p>Jeremy, You've done a lot of our memory profiling lately, what's
your take?</p></div>
false
2008-11-13T09:39:48+00:00
28420
---
:assigned_user: 141
:milestone: 9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-13T09:39:55+00:00
141
Michael Koziarski
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
Jeremy Kemper
85
1
What was the application you were testing, how many AR models were involved? It's AR which makes extensive use of define_method, especially in associations?
<div><p>What was the application you were testing, how many AR models
were involved? It's AR which makes extensive use of define_method,
especially in associations?</p></div>
false
2008-11-13T09:41:27+00:00
28420
--- {}
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-13T09:41:31+00:00
141
Michael Koziarski
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
Jeremy Kemper
85
1
Test app was [1] with a new action that just returned a blank page.
So not a very good test at all.
As mentioned, this was a bit of a botch job.
I'll try and do some more testing on a more representative app soon. Any idea what this app should involve? Or do we have a good standard test case?
[1] http://rails.lighthouseapp.com/attachments/59425/lighthouse-ticket-1290.zip
<div><p>Test app was <a href="/projects/8994/changesets/1" title="Changeset #1">[1]</a> with a new action that just returned a blank
page.</p>
<p>So not a very good test at all.</p>
<p>As mentioned, this was a bit of a botch job.</p>
<p>I'll try and do some more testing on a more representative app
soon. Any idea what this app should involve? Or do we have a good
standard test case?</p>
<p><a href="/projects/8994/changesets/1" title="Changeset #1">[1]</a> <a href="http://rails.lighthouseapp.com/attachments/59425/lighthouse-ticket-1290.zip">
http://rails.lighthouseapp.com/a...</a></p></div>
false
2008-11-13T09:55:01+00:00
28420
--- {}
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-13T09:55:04+00:00
28420
Tom Lea
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
Jeremy Kemper
85
1
I think it would be great to get this fixed. But we need to make sure we're not just adding back the leaking headache. I remember before we had this and it wasn't pretty. You'd have to restart your dev server pretty often on a complex app.
Perhaps this is no longer valid, but we should absolutely confirm that before including it. So I say we don't aim for 2.2 final, but as soon as we have a confirmation, we put it in there.
<div><p>I think it would be great to get this fixed. But we need to make
sure we're not just adding back the leaking headache. I remember
before we had this and it wasn't pretty. You'd have to restart your
dev server pretty often on a complex app.</p>
<p>Perhaps this is no longer valid, but we should absolutely
confirm that before including it. So I say we don't aim for 2.2
final, but as soon as we have a confirmation, we put it in
there.</p></div>
false
2008-11-13T10:08:20+00:00
28420
---
:milestone: 12671
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-11-13T10:08:22+00:00
83
DHH
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
1
Guys,
<usual newbie apologies>
I get the exact same error as described at the top of ref2 (duplicate ticket) using ActiveRecord::Base#hash. (First I do Object.const_set(name, AR_subclass then, when running AR#hash a second time - after reload - it happens.)
Can anyone help out a newcomer that don't understand the suggestions above:
- Should I apply the patch and how? Am I supposed to edit the source to try replicate the diff?
- Is there a workaround? If so, where can I find instructions?
- If no, shouldn't this be high prio ticket, or is this weird/unusual use of RoR?
- The difficulty of understanding what is going and the impression of side-effects is making a newcomer a bit worried:
Array#uniq fails because AR#hash fails after reload because AR works differently when defining subclasses "dynamically" - none of which is easy to see or explained anywhere. etc etc
I use Rails 2.2.2 on jruby 1.1.5 (ruby 1.8.6 patchlevel 114) (2008-11-03 rev 7996) on Java 1.6 and win XP
<div><p>Guys, I get the exact same error as described at the top of ref2
(duplicate ticket) using ActiveRecord::Base#hash. (First I do
Object.const_set(name, AR_subclass then, when running AR#hash a
second time - after reload - it happens.)</p>
<p>Can anyone help out a newcomer that don't understand the
suggestions above: - Should I apply the patch and how? Am I
supposed to edit the source to try replicate the diff? - Is there a
workaround? If so, where can I find instructions? - If no,
shouldn't this be high prio ticket, or is this weird/unusual use of
RoR? - The difficulty of understanding what is going and the
impression of side-effects is making a newcomer a bit worried:
Array#uniq fails because AR#hash fails after reload because AR
works differently when defining subclasses "dynamically" - none of
which is easy to see or explained anywhere. etc etc</p>
<p>I use Rails 2.2.2 on jruby 1.1.5 (ruby 1.8.6 patchlevel 114)
(2008-11-03 rev 7996) on Java 1.6 and win XP</p></div>
false
2008-12-07T00:17:01+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2008-12-07T00:17:02+00:00
40008
Gunnar Djurberg
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
1
Having encountered this problem myself (and being stuck on it repeateadly) I have investigated the error (and hopefully found a good fix). Here's what I know about it:
1. It happens when ActiveRecord::Base#reset_subclasses is called by the dispatcher between requests (in dev mode only).
2. ActiveRecord::Base#reset_subclasses wipes out the inheritable_attributes Hash (where #skip_time_zone_conversion_for_attributes is stored).
3. It will not only happen on objects persisted through requests, as the "monkey test app" from #1290 shows, but also when trying to access generated association methods on AR, even for objects that live only on the current request.
4. This bug was introduced by [this commit](http://github.com/rails/rails/commit/9c4730d01e892df8d5c5493a08e0cddf0de5d575) where the #skip_time_zone_conversion_for_attributes declaration was changed from base.cattr_accessor to base.class_inheritable_accessor. But then again, that same commit also fixed something else.
5. The patch initially submitted here that simply avoids clearing the instance_variables and instance_methods in reset_subclasses does introduce massive leaking, and the amounts leaked seem directly proportional to complexity of the app (i.e. number of models, associations and attributes on each of them). I have a pretty complex app which leaks nearly 1Mb on each request in dev mode when the patch is applied. So it's not viable (for me anyways).
6. While trying out different ways to solve this, I have corrected the initial error (skip_time_zone_conversion_for_attributes being nil on 2nd request), but it uncovered another error (which just didn't happen because the first exception would be raised before getting to it). That error seems to be the one reported in #774 (Stack overflow in method_missing for the 'id' method).
Now, for the solution, my patch (attached) does the following:
1. It adds wrapper methods for #skip_time_zone_conversion_for_attributes methods, making sure it always reads/writes the value as an class_inheritable_attribute. This way, nil is never returned anymore.
2. It ensures that the 'id' method is not wiped out when reset_subclasses is called. AR is kinda strange on that one, because it first defines it directly in the source, but redefines itself with #define_read_method when it is first called. And that is precisely what makes it fail after reloading (since reset_subclasses then wipes it out).
I also added a test in reload_models_test.rb, which calls reset_subclasses to try and simulate reloading between requests in dev mode. What I cannot tell at this point is if it really triggers the reloading mechanism as it does on a live dispatcher request cycle. I also tested from script/server and the error was gone.
Comments, opinions (and probably further testing) are welcome.
Regards,
<div><p>Having encountered this problem myself (and being stuck on it
repeateadly) I have investigated the error (and hopefully found a
good fix). Here's what I know about it:</p>
<ol>
<li>It happens when ActiveRecord::Base#reset_subclasses is called
by the dispatcher between requests (in dev mode only).</li>
<li>ActiveRecord::Base#reset_subclasses wipes out the
inheritable_attributes Hash (where
#skip_time_zone_conversion_for_attributes is stored).</li>
<li>It will not only happen on objects persisted through requests,
as the "monkey test app" from <a href="/projects/8994/tickets/1290" title="Ticket #1290">#1290</a> shows, but also when trying to
access generated association methods on AR, even for objects that
live only on the current request.</li>
<li>This bug was introduced by <a href="http://github.com/rails/rails/commit/9c4730d01e892df8d5c5493a08e0cddf0de5d575">
this commit</a> where the #skip_time_zone_conversion_for_attributes
declaration was changed from base.cattr_accessor to
base.class_inheritable_accessor. But then again, that same commit
also fixed something else.</li>
<li>The patch initially submitted here that simply avoids clearing
the instance_variables and instance_methods in reset_subclasses
does introduce massive leaking, and the amounts leaked seem
directly proportional to complexity of the app (i.e. number of
models, associations and attributes on each of them). I have a
pretty complex app which leaks nearly 1Mb on each request in dev
mode when the patch is applied. So it's not viable (for me
anyways).</li>
<li>While trying out different ways to solve this, I have corrected
the initial error (skip_time_zone_conversion_for_attributes being
nil on 2nd request), but it uncovered another error (which just
didn't happen because the first exception would be raised before
getting to it). That error seems to be the one reported in <a href="/projects/8994/tickets/774" title="Ticket #774">#774</a> (Stack
overflow in method_missing for the 'id' method).</li>
</ol>
<p>Now, for the solution, my patch (attached) does the
following:</p>
<ol>
<li>It adds wrapper methods for
#skip_time_zone_conversion_for_attributes methods, making sure it
always reads/writes the value as an class_inheritable_attribute.
This way, nil is never returned anymore.</li>
<li>It ensures that the 'id' method is not wiped out when
reset_subclasses is called. AR is kinda strange on that one,
because it first defines it directly in the source, but redefines
itself with #define_read_method when it is first called. And that
is precisely what makes it fail after reloading (since
reset_subclasses then wipes it out).</li>
</ol>
<p>I also added a test in reload_models_test.rb, which calls
reset_subclasses to try and simulate reloading between requests in
dev mode. What I cannot tell at this point is if it really triggers
the reloading mechanism as it does on a live dispatcher request
cycle. I also tested from script/server and the error was gone.</p>
<p>Comments, opinions (and probably further testing) are
welcome.</p>
<p>Regards,</p></div>
false
2009-01-06T19:13:49+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-06T19:13:53+00:00
42669
C. Bedard
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
2
I think it's fine to add getter and setter wrapper methods around skip_time_zone_conversion_for_attributes -- this would remove the need to use an explicit +self+ receiver whenever you need to declare these attributes in a model -- and it does address *some* of the issues found with calling methods on cached models: i.e., you can now call method_missing-defined methods without failure.
But keep in mind, with or without this fix, there's still a problem with user-defined methods on a model being removed -- in the Monkey app, the Monkey model defines a #> method (it could be named #foo or whatever) and this method fails on the second page refresh, with or without a skip_time_zone_ fix.
<div><p>I think it's fine to add getter and setter wrapper methods
around skip_time_zone_conversion_for_attributes -- this would
remove the need to use an explicit +self+ receiver whenever you
need to declare these attributes in a model -- and it does address
<em>some</em> of the issues found with calling methods on cached
models: i.e., you can now call method_missing-defined methods
without failure.</p>
<p>But keep in mind, with or without this fix, there's still a
problem with user-defined methods on a model being removed -- in
the Monkey app, the Monkey model defines a #> method (it could
be named #foo or whatever) and this method fails on the second page
refresh, with or without a skip_time_zone_ fix.</p></div>
false
2009-01-07T05:59:47+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-07T05:59:52+00:00
15783
Geoff Buesing
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
2
I get the same error too, only in development mode.
Environment: Mac OSX 10.5, Rails 2.2.2, Mongrel 1.1.5, ruby 1.8.6 (2008-03-03 patchlevel 114)
In my case, the error appears when the app call a observer. I fix it changing "config.time_zone = 'Madrid'" for "config.active_record.default_timezone = 'Madrid'" in environment.rb
In my case the solution proposed by Geoff in #1290 doesn't work.
<div><p>I get the same error too, only in development mode.</p>
<p>Environment: Mac OSX 10.5, Rails 2.2.2, Mongrel 1.1.5, ruby
1.8.6 (2008-03-03 patchlevel 114)</p>
<p>In my case, the error appears when the app call a observer. I
fix it changing "config.time_zone = 'Madrid'" for
"config.active_record.default_timezone = 'Madrid'" in
environment.rb</p>
<p>In my case the solution proposed by Geoff in <a href="/projects/8994/tickets/1290" title="Ticket #1290">#1290</a>
doesn't work.</p></div>
false
2009-01-07T08:20:48+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-07T08:20:51+00:00
33400
Emili Parreño
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
2
In my view, the Monkey app, while it does produce our error, uses the Rails framework in a specific way that is more related to persistence across requests than standard use of an AR instance.
The intended and expected behavior of the framework is to allow to create, use and dispose of an AR object within a single request (and repeat that consistently on each request).
I'm not saying that Rails shouldn't provide functionality to allow to do what the Monkey app does (which it already does if serialization was used), but that would represent an addition to the framework (as opposed to currently being a bug on expected behavior).
It would be very nice to come up with a way that addresses both problems at once, but the way the reloading works does not allow that, because it creates *new* class instances on each request, instead of stripping a class instance from its methods and attributes and re-applying them to the same instance.
In the case of the Monkey app, if MONKEY_ONE is to be initialized that early and be kept throughout the life of the application, auto-reloading can (and should) be avoided with a simple explicit require (in extensions.rb) :
@@@ruby
require File.join(RAILS_ROOT,'app/models/monkey')
MONKEY_ONE = Monkey.first
@@@
And now the Monkey is not so amnesic anymore ;-)
`ActiveSupport::Dependencies` only autoloads missing classes (constants) and the dispatcher only unloads the autoloaded classes in `#cleanup_application`. This is why, for example, classes defined in plugins do not unload automatically.
Of course, there may be other issues with reloading that we are not aware of, and I'll be glad to help if anything else comes up.
<div><p>In my view, the Monkey app, while it does produce our error,
uses the Rails framework in a specific way that is more related to
persistence across requests than standard use of an AR
instance.</p>
<p>The intended and expected behavior of the framework is to allow
to create, use and dispose of an AR object within a single request
(and repeat that consistently on each request).</p>
<p>I'm not saying that Rails shouldn't provide functionality to
allow to do what the Monkey app does (which it already does if
serialization was used), but that would represent an addition to
the framework (as opposed to currently being a bug on expected
behavior).</p>
<p>It would be very nice to come up with a way that addresses both
problems at once, but the way the reloading works does not allow
that, because it creates <em>new</em> class instances on each
request, instead of stripping a class instance from its methods and
attributes and re-applying them to the same instance.</p>
<p>In the case of the Monkey app, if MONKEY_ONE is to be
initialized that early and be kept throughout the life of the
application, auto-reloading can (and should) be avoided with a
simple explicit require (in extensions.rb) :</p>
<p>@@@ruby require File.join(RAILS_ROOT,'app/models/monkey')</p>
<p>MONKEY_ONE = Monkey.first</p>
<pre><code>
And now the Monkey is not so amnesic anymore ;-)
`ActiveSupport::Dependencies` only autoloads missing classes (constants) and the dispatcher only unloads the autoloaded classes in `#cleanup_application`. This is why, for example, classes defined in plugins do not unload automatically.
Of course, there may be other issues with reloading that we are not aware of, and I'll be glad to help if anything else comes up.
</code></pre></div>
false
2009-01-07T15:52:33+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-07T15:52:36+00:00
42669
C. Bedard
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
2
Sorry about the poor formatting in my previous message...(A preview function would be nice in here :-S ).
<div><p>Sorry about the poor formatting in my previous message...(A
preview function would be nice in here :-S ).</p></div>
false
2009-01-07T15:56:49+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-07T15:56:52+00:00
42669
C. Bedard
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
2
@Emili -- config.active_record.default_timezone represents the zone that times are persisted in -- you can only set this to :utc or :local; 'Madrid' is not a valid setting. If you're using config.time_zone, you don't need to set active_record.default_timezone, because this will automatically set it to :utc for you.
With config.time_zone = 'Madrid', and with no explicit active_record.default_timezone setting, are you still experiencing issues?
@C. Bedard -- one thing that's not clear for me: in your previous comment, you refer to an issue "when trying to access generated association methods on AR, even for objects that live only on the current request" Do we have an example of this issue?
<div><p>@Emili -- config.active_record.default_timezone represents the
zone that times are persisted in -- you can only set this to :utc
or :local; 'Madrid' is not a valid setting. If you're using
config.time_zone, you don't need to set
active_record.default_timezone, because this will automatically set
it to :utc for you.</p>
<p>With config.time_zone = 'Madrid', and with no explicit
active_record.default_timezone setting, are you still experiencing
issues?</p>
<p>@C. Bedard -- one thing that's not clear for me: in your
previous comment, you refer to an issue "when trying to access
generated association methods on AR, even for objects that live
only on the current request" Do we have an example of this
issue?</p></div>
false
2009-01-07T18:01:45+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-07T18:01:50+00:00
15783
Geoff Buesing
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
2
@Geoff:
I have made an example (attached) that triggers the error without persisting AR objects between requests. I try and explain as cleary as possible what goes on (from what I understand) in the app README.
Basically what happens is that a file that is explicitely required (with `require 'file'`), it will not be reloaded on each request, while the class it declares is being wiped out by ActiveRecord::Base#reset_subclasses. On 2nd request, the class remain "empty"...
Obviously, the whole thing can be avoided by never using `require` in files that declare AR subclasses. But there can be contexts in which explicit requires are needed (I have an app for which it is the case).
<div><p>@Geoff:</p>
<p>I have made an example (attached) that triggers the error
without persisting AR objects between requests. I try and explain
as cleary as possible what goes on (from what I understand) in the
app README.</p>
<p>Basically what happens is that a file that is explicitely
required (with <code>require 'file'</code>), it will not be
reloaded on each request, while the class it declares is being
wiped out by ActiveRecord::Base#reset_subclasses. On 2nd request,
the class remain "empty"...</p>
<p>Obviously, the whole thing can be avoided by never using
<code>require</code> in files that declare AR subclasses. But there
can be contexts in which explicit requires are needed (I have an
app for which it is the case).</p></div>
false
2009-01-08T05:36:24+00:00
28420
---
:tag: activerecord bug reload
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-08T05:36:29+00:00
42669
C. Bedard
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
3
@C. Bedard -- thanks for the example, very helpful to have this. I think you're right about the explicit require mucking up the works with Dependencies and class reloading.
I did some experiments with the app, here's what I found:
1. with the require for another AR-model declared at the top of Monkey, you get an exception on the second request (as promised.) The stack trace stops at a NoMethodError for skip_time_zone_
2. *without* the require, things work fine (again, as promised.)
3. if I move the user_role require from Monkey to the bottom of environment.rb, I experience the same issue on the second request.
4. *with* the require, but if I add this method to each of the models:
@@@ ruby
def self.skip_time_zone_conversion_for_attributes
[]
end
@@@
things work fine. This is similar to what your patch does, i.e., work around the class inheritable accessor issue with skip_time_zone_.
HOWEVER:
5. *with* the require, and *with* skip_time_zone_ explicitly declared as a class method, if I declare a method #foo in Role, and then I change this line in the view from:
@@@ ruby
# calling a Role attribute method defined by method_missing:
u.user_roles.collect { |ur| ur.role.description }.join(", ")
@@@
to
@@@ ruby
# calling a method explicitly defined in Role class:
u.user_roles.collect { |ur| ur.role.foo }.join(", ")
@@@
...I get a NoMethodError on the *second* request -- the stack trace tops out at method_missing.
So, it seems like this reload issue is very similar to the issue with objects cached between requests -- there's the class inheritable accessor issue with skip_time_zone_, but even if you work around that, there are issues with calling methods that aren't regenerated by method_missing.
Possible solutions for these problems:
1. for the issue with objects cached between requests -- we can instruct users to always use Rails.cache with a marshaling memory store
2. for the explicit require issue -- we can instruct users to never explicitly require an AR model when reloading is desired, as you suggest.
<div><p>@C. Bedard -- thanks for the example, very helpful to have this.
I think you're right about the explicit require mucking up the
works with Dependencies and class reloading.</p>
<p>I did some experiments with the app, here's what I found:</p>
<ol>
<li>
<p>with the require for another AR-model declared at the top of
Monkey, you get an exception on the second request (as promised.)
The stack trace stops at a NoMethodError for skip_time_zone_</p>
</li>
<li>
<p><em>without</em> the require, things work fine (again, as
promised.)</p>
</li>
<li>
<p>if I move the user_role require from Monkey to the bottom of
environment.rb, I experience the same issue on the second
request.</p>
</li>
<li>
<p><em>with</em> the require, but if I add this method to each of
the models:</p>
</li>
</ol>
<pre><code class="ruby">
def self.skip_time_zone_conversion_for_attributes
[]
end
</code></pre>
<p>things work fine. This is similar to what your patch does, i.e.,
work around the class inheritable accessor issue with
skip_time_zone_.</p>
<p>HOWEVER:</p>
<ol>
<li><em>with</em> the require, and <em>with</em> skip_time_zone_
explicitly declared as a class method, if I declare a method #foo
in Role, and then I change this line in the view from:</li>
</ol>
<pre><code class="ruby">
# calling a Role attribute method defined by method_missing:
u.user_roles.collect { |ur| ur.role.description }.join(", ")
</code></pre>
<p>to</p>
<pre><code class="ruby">
# calling a method explicitly defined in Role class:
u.user_roles.collect { |ur| ur.role.foo }.join(", ")
</code></pre>
<p>...I get a NoMethodError on the <em>second</em> request -- the
stack trace tops out at method_missing.</p>
<p>So, it seems like this reload issue is very similar to the issue
with objects cached between requests -- there's the class
inheritable accessor issue with skip_time_zone_, but even if you
work around that, there are issues with calling methods that aren't
regenerated by method_missing.</p>
<p>Possible solutions for these problems:</p>
<ol>
<li>
<p>for the issue with objects cached between requests -- we can
instruct users to always use Rails.cache with a marshaling memory
store</p>
</li>
<li>
<p>for the explicit require issue -- we can instruct users to never
explicitly require an AR model when reloading is desired, as you
suggest.</p>
</li>
</ol></div>
false
2009-01-08T15:44:52+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-08T15:44:57+00:00
15783
Geoff Buesing
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
3
@C. Bedard -- in regards to your patch: by working around issues with #id and #skip_time_zone_, you may just be pushing the problem further downstream, instead of truly fixing things.
<div><p>@C. Bedard -- in regards to your patch: by working around issues
with #id and #skip_time_zone_, you may just be pushing the problem
further downstream, instead of truly fixing things.</p></div>
false
2009-01-08T16:05:23+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-08T16:05:27+00:00
15783
Geoff Buesing
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
3
@Geoff:
Indeed my patch doesn't solve the problem. I didn't think at that time that it was related to dependencies.
If `skip_time_zone_for_attributes` actually contained some fields, they would be cleared after 1st request and since the class would never reload on 2nd request, it would be silently reset to an empty array. Same goes for any other method (my patch actually dealt with the `id` method also, but that was a short-sighted fix since all methods are undef'ed).
And I would add to your second suggestion:
*If* an explicit `require` is needed, then those model files should be loaded on app initialization and users would need to understand they lose the reloading functionality for those models in dev mode.
As for you suggestion to persist objects to the Rails.cache, I am not too familiar on how it works, but how would an object cope with being tied to a Class that has been stripped from its method declarations?
Does the Class instance get cached too? And if so, isn't it the same as not reloading it?
<div><p>@Geoff:</p>
<p>Indeed my patch doesn't solve the problem. I didn't think at
that time that it was related to dependencies.</p>
<p>If <code>skip_time_zone_for_attributes</code> actually contained
some fields, they would be cleared after 1st request and since the
class would never reload on 2nd request, it would be silently reset
to an empty array. Same goes for any other method (my patch
actually dealt with the <code>id</code> method also, but that was a
short-sighted fix since all methods are undef'ed).</p>
<p>And I would add to your second suggestion:</p>
<p><em>If</em> an explicit <code>require</code> is needed, then
those model files should be loaded on app initialization and users
would need to understand they lose the reloading functionality for
those models in dev mode.</p>
<p>As for you suggestion to persist objects to the Rails.cache, I
am not too familiar on how it works, but how would an object cope
with being tied to a Class that has been stripped from its method
declarations? Does the Class instance get cached too? And if so,
isn't it the same as not reloading it?</p></div>
false
2009-01-08T16:55:22+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-08T16:55:24+00:00
42669
C. Bedard
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
3
@Geoff: thanks for the explanation. I experiencing issues everytime that I set config.time_zone = 'Madrid' (I tried to set the time_zone = 'Paris' and I experiencing the same problem). If I comment this line and start the app with active_record.default_timezone :local or :utc, all works ok.
<div><p>@Geoff: thanks for the explanation. I experiencing issues
everytime that I set config.time_zone = 'Madrid' (I tried to set
the time_zone = 'Paris' and I experiencing the same problem). If I
comment this line and start the app with
active_record.default_timezone :local or :utc, all works ok.</p></div>
false
2009-01-10T06:49:28+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-10T06:49:35+00:00
33400
Emili Parreño
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
3
@C. Bedard -- if the Rails.cache memory store marshaled objects before storing, and unmarshaled them on retrieval, then it would never return instances of stripped-down classes: unmarshaling would re-create instances with current class definitions.
@Emili: to be clear, all works ok *if* you avoid calling methods that can't be generated via method_missing on cached instances.
<div><p>@C. Bedard -- if the Rails.cache memory store marshaled objects
before storing, and unmarshaled them on retrieval, then it would
never return instances of stripped-down classes: unmarshaling would
re-create instances with current class definitions.</p>
<p>@Emili: to be clear, all works ok <em>if</em> you avoid calling
methods that can't be generated via method_missing on cached
instances.</p></div>
false
2009-01-11T20:53:59+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-11T20:54:04+00:00
15783
Geoff Buesing
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
3
Perhaps the best bet here is to provide a patch which makes just the one potentially leaking change. Ideally one that applies cleanly to 2.2
We can then ask people to run their apps in development with it turned on and report the numbers back
It'd be great to fix this finally, and to do so knowing we're not going to be wasting too much ram
<div><p>Perhaps the best bet here is to provide a patch which makes just
the one potentially leaking change. Ideally one that applies
cleanly to 2.2</p>
<p>We can then ask people to run their apps in development with it
turned on and report the numbers back</p>
<p>It'd be great to fix this finally, and to do so knowing we're
not going to be wasting too much ram</p></div>
false
2009-01-12T06:30:55+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-12T06:30:59+00:00
141
Michael Koziarski
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
3
@Koz would that be a patch along the lines of the original one attached to the ticket? or something else? I'm happy to rebase it if that is the case. It is definitely leaky in dev, but just how leaky in a large app is still unknown.
<div><p>@Koz would that be a patch along the lines of the original one
attached to the ticket? or something else? I'm happy to rebase it
if that is the case. It is definitely leaky in dev, but just how
leaky in a large app is still unknown.</p></div>
false
2009-01-12T08:46:52+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-12T08:46:54+00:00
28420
Tom Lea
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
3
Yep, if it still applies cleanly to master and/or 2-2-stable just let me know.
<div><p>Yep, if it still applies cleanly to master and/or 2-2-stable
just let me know.</p></div>
false
2009-01-12T09:10:06+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-12T09:10:08+00:00
141
Michael Koziarski
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
3
The attached patch applies cleanly to both master and 2-2-stable, I've updated the commit note to be a bit more descriptive, but obviously feel free to edit.
<div><p>The attached patch applies cleanly to both master and
2-2-stable, I've updated the commit note to be a bit more
descriptive, but obviously feel free to edit.</p></div>
false
2009-01-12T10:28:26+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-12T10:28:30+00:00
28420
Tom Lea
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
@Geoff: You're saying "...then it would never return instances of stripped-down classes: unmarshaling would re-create instances with current class definitions."
From what I understand, the "current class definitions" after reloading *are* stripped-down. So if an explicit `require` (as in my example app) was used (mocking up the Dependencies autoload), marshalling an instance would not change the fact that its Class has lost its methods since it is not reloaded.
@Michael: I have tested the patch and as I mentioned earlier, it does leak in dev mode. Here are my test results (same app, same request 100 times in a loop):
With patch:
Initial memory usage: 40 092 Kb
after 100 requests : 120 104 Kb
Without patch:
Initial memory usage: 40 168 Kb
after 100 requests : 61 824 Kb
The leak seems to be proportional to the number of methods and attributes of all AR subclasses (which makes sense since it is the instance_vars and instance_methods that do not get cleared anymore).
Note that memory usage keeps growing in dev mode regardless of the patch (probably pointing to other leaks in dev mode (?).
<div><p>@Geoff: You're saying "...then it would never return instances
of stripped-down classes: unmarshaling would re-create instances
with current class definitions."</p>
<p>From what I understand, the "current class definitions" after
reloading <em>are</em> stripped-down. So if an explicit
<code>require</code> (as in my example app) was used (mocking up
the Dependencies autoload), marshalling an instance would not
change the fact that its Class has lost its methods since it is not
reloaded.</p>
<p>@Michael: I have tested the patch and as I mentioned earlier, it
does leak in dev mode. Here are my test results (same app, same
request 100 times in a loop):</p>
<p>With patch: Initial memory usage: 40 092 Kb after 100 requests :
120 104 Kb</p>
<p>Without patch: Initial memory usage: 40 168 Kb after 100
requests : 61 824 Kb</p>
<p>The leak seems to be proportional to the number of methods and
attributes of all AR subclasses (which makes sense since it is the
instance_vars and instance_methods that do not get cleared
anymore).</p>
<p>Note that memory usage keeps growing in dev mode regardless of
the patch (probably pointing to other leaks in dev mode (?).</p></div>
false
2009-01-12T17:27:54+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-12T17:28:00+00:00
42669
C. Bedard
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
Also, come to think of it: Tom's patch, by not stripping down the subclasses, does not address the underlying issue (which is really that an AR subclass might not be reloaded on each request because Dependencies has skipped it if it was explicitly required somewhere). So basically, the error is not raised anymore because the app holds on to the initial class definition which is not being stripped-down anymore.
As my patch did, it only hides the fact that the Class is not being reloaded.
You can try this with the Monkey App with the patch applied: Launch the app, hit it with a first request, then remove the `def >(object)` method. If you hit the server again with more requests, no error is raised, and the `>` method is still defined (which it should not if the class has been reloaded).
`MONKEY_ONE.class == @monkey_two.class # => false`
<div><p>Also, come to think of it: Tom's patch, by not stripping down
the subclasses, does not address the underlying issue (which is
really that an AR subclass might not be reloaded on each request
because Dependencies has skipped it if it was explicitly required
somewhere). So basically, the error is not raised anymore because
the app holds on to the initial class definition which is not being
stripped-down anymore.</p>
<p>As my patch did, it only hides the fact that the Class is not
being reloaded.</p>
<p>You can try this with the Monkey App with the patch applied:
Launch the app, hit it with a first request, then remove the
<code>def >(object)</code> method. If you hit the server again
with more requests, no error is raised, and the <code>></code>
method is still defined (which it should not if the class has been
reloaded). <code>MONKEY_ONE.class == @monkey_two.class # =>
false</code></p></div>
false
2009-01-12T18:11:41+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-12T18:11:46+00:00
42669
C. Bedard
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
@C. Bedard: Just to be clear, the patch does not make magic happen, all instances remain instances of the class they always were instances off. When the contsants that reference the classes (the constant `Monkey` in this case) are undefined by Dependencies, the instances still refer to the classes they were instantiated from.
This is how it works with standard classes (Object.remove_const is effectively the reload):
@@@ ruby
class Foo
def bar
10
end
end
baz = Foo.new
baz.bar #=> 10
Object.send :remove_const, :Foo
class Foo
def bar
20
end
end
baz.bar #=> 10
bam = Foo.new
bam.bar #=> 20
@@@
`baz` is and always will be an instance of the first Foo (from before the reload), and this is always the case. It cannot be changed and will refuse to mutate.
The same is true of active record classes. The only difference here is that special code (that code removed by the patch) strips out the original instance methods, and leaves the instances disfigured and unpleasant to the touch.
The class has been redefined, and new instances will behave as expected, but existing instances will be different.
Another example to further the point that Monkey and Monkey after the reload are different entities:
@@@ ruby
class Foo
end
foo_one = Foo.object_id
Object.send :remove_const, :Foo
class Foo
end
foo_two = Foo.object_id
p :foo_one => foo_one, :foo_two => foo_two
# >> {:foo_one=>1701840, :foo_two=>1701810}
@@@
So in conclusion, classes are not reloaded, they are recreated. Making them reload is for another time and another place... and is not easy looking.
p.s. If I lost my point somewhere in there, it's because it's 6:42pm here, and I've had a long day of I18n cards ;).
<div><p>@C. Bedard: Just to be clear, the patch does not make magic
happen, all instances remain instances of the class they always
were instances off. When the contsants that reference the classes
(the constant <code>Monkey</code> in this case) are undefined by
Dependencies, the instances still refer to the classes they were
instantiated from.</p>
<p>This is how it works with standard classes (Object.remove_const
is effectively the reload):</p>
<pre><code class="ruby">
class Foo
def bar
10
end
end
baz = Foo.new
baz.bar #=> 10
Object.send :remove_const, :Foo
class Foo
def bar
20
end
end
baz.bar #=> 10
bam = Foo.new
bam.bar #=> 20
</code></pre>
<p><code>baz</code> is and always will be an instance of the first
Foo (from before the reload), and this is always the case. It
cannot be changed and will refuse to mutate.</p>
<p>The same is true of active record classes. The only difference
here is that special code (that code removed by the patch) strips
out the original instance methods, and leaves the instances
disfigured and unpleasant to the touch.</p>
<p>The class has been redefined, and new instances will behave as
expected, but existing instances will be different.</p>
<p>Another example to further the point that Monkey and Monkey
after the reload are different entities:</p>
<pre><code class="ruby">
class Foo
end
foo_one = Foo.object_id
Object.send :remove_const, :Foo
class Foo
end
foo_two = Foo.object_id
p :foo_one => foo_one, :foo_two => foo_two
# >> {:foo_one=>1701840, :foo_two=>1701810}
</code></pre>
<p>So in conclusion, classes are not reloaded, they are recreated.
Making them reload is for another time and another place... and is
not easy looking.</p>
<p>p.s. If I lost my point somewhere in there, it's because it's
6:42pm here, and I've had a long day of I18n cards ;).</p></div>
false
2009-01-12T18:43:21+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-12T18:43:27+00:00
28420
Tom Lea
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
This caused me a major headache. I am modifying Community Engine and was getting first the time zone error, then I set environment to use local time and I got random NoMethod on second page load on methods defined in my models. I tried the patch and it fixes my issue.
<div><p>This caused me a major headache. I am modifying Community Engine
and was getting first the time zone error, then I set environment
to use local time and I got random NoMethod on second page load on
methods defined in my models. I tried the patch and it fixes my
issue.</p></div>
false
2009-01-25T07:08:53+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-25T07:08:56+00:00
44881
Christian Gregertsen
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
I see similar leak statistics to What C. Bedard mentioned. 60M after 100 requests.
This isn't an acceptable cost to pay for this problem sorry, it's around 600k per request for an app with only around 15 models and associated associations. So we need another fix which doesn't leak that memory.
Another option would be to make the 'vestigial classes' have a method_missing which showed a very detailed error message about what happened, and what they can do about it.
<div><p>I see similar leak statistics to What C. Bedard mentioned. 60M
after 100 requests.</p>
<p>This isn't an acceptable cost to pay for this problem sorry,
it's around 600k per request for an app with only around 15 models
and associated associations. So we need another fix which doesn't
leak that memory.</p>
<p>Another option would be to make the 'vestigial classes' have a
method_missing which showed a very detailed error message about
what happened, and what they can do about it.</p></div>
false
2009-01-26T03:19:21+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-01-26T03:19:23+00:00
141
Michael Koziarski
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
Even after applying the patch I get an error at the 1st reload of a page, when I include a related model in the caching:
<code>class Project < ActiveRecord::Base
...
belongs_to :person
...
def self.all_cached
Rails.cache.fetch('Project.all_sort_name') { Project.sname_sort }
end
def self.sname_sort
Project.all(:include => 'person', :order => 'people.sname ASC')
end</code>
This gives me a
<code>Argument error "undefined class/module Person"</code>
after reloading (2nd display) in development mode. This doesn't happen in production mode, or after terminating/restarting memcached which is used as caching server.
<div><p>Even after applying the patch I get an error at the 1st reload
of a page, when I include a related model in the caching:</p>
<p><code>class Project < ActiveRecord::Base ... belongs_to
:person ... def self.all_cached
Rails.cache.fetch('Project.all_sort_name') { Project.sname_sort }
end</code></p>
<p>def self.sname_sort Project.all(:include => 'person', :order
=> 'people.sname ASC') end</p>
<p>This gives me a</p>
<p><code>Argument error "undefined class/module Person"</code></p>
<p>after reloading (2nd display) in development mode. This doesn't
happen in production mode, or after terminating/restarting
memcached which is used as caching server.</p></div>
false
2009-02-09T14:38:40+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-02-09T14:38:42+00:00
46732
Frank Wöckener
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
What's the status of this bug ? I have this problem in JRuby environment.
Can we just add :default param for default value of class_inheritable_accessor ?
example:
@@@ ruby
base.class_inheritable_accessor :skip_time_zone_conversion_for_attributes, :instance_writer => false, :default => []
@@@
<div><p>What's the status of this bug ? I have this problem in JRuby
environment.</p>
<p>Can we just add :default param for default value of
class_inheritable_accessor ?</p>
<p>example:</p>
<pre><code class="ruby">
base.class_inheritable_accessor :skip_time_zone_conversion_for_attributes, :instance_writer => false, :default => []
</code></pre></div>
false
2009-03-06T19:05:33+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-03-06T19:05:37+00:00
11785
Paweł Kondzior
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
@pawel: As far as I am aware, this is still unresolved.
The 'real world' memory leaks reported are unacceptable. Much bigger than I expected, so this solution is officially pants.
Sorry I've gone a little 'dark' on this one, as I am basically out of ideas, and am no longer feeling the hurt at work. The 'vestigial classes' solution is not one I am a particularly large fan of, but it may well be the only suitable compromise for the general case (not a cache store).
We could still do well to patch the MemoryStore to do one of the following:
* Marshal everything (just like the file store), but this takes an unknown performance hit.
* Marshal when not caching classes, to allow testing caching stuff in dev mode.
* Make MemoryStore a null cache when reloading classes is enabled.
* Refuse to use MemoryStore when class reloading is enabled.
The first one may compromise the performance of the memory store, the second two feel like nasty nasty hacks, and I'm still not sure about the last one, feels too violent.
Anyone fancy writing a patch for the vestigial classes to see how it feels?
Anyone got any more thoughts on dealing with the memory cache?
<div><p>@pawel: As far as I am aware, this is still unresolved.</p>
<p>The 'real world' memory leaks reported are unacceptable. Much
bigger than I expected, so this solution is officially pants.</p>
<p>Sorry I've gone a little 'dark' on this one, as I am basically
out of ideas, and am no longer feeling the hurt at work. The
'vestigial classes' solution is not one I am a particularly large
fan of, but it may well be the only suitable compromise for the
general case (not a cache store).</p>
<p>We could still do well to patch the MemoryStore to do one of the
following:</p>
<ul>
<li>Marshal everything (just like the file store), but this takes
an unknown performance hit.</li>
<li>Marshal when not caching classes, to allow testing caching
stuff in dev mode.</li>
<li>Make MemoryStore a null cache when reloading classes is
enabled.</li>
<li>Refuse to use MemoryStore when class reloading is enabled.</li>
</ul>
<p>The first one may compromise the performance of the memory
store, the second two feel like nasty nasty hacks, and I'm still
not sure about the last one, feels too violent.</p>
<p>Anyone fancy writing a patch for the vestigial classes to see
how it feels? Anyone got any more thoughts on dealing with the
memory cache?</p></div>
false
2009-03-06T22:21:56+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-03-06T22:22:03+00:00
28420
Tom Lea
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
The issue is slightly broader than just the cache stores though,
you'll have the same issues if you used:
$foo ||= Foo.first
# next request
$foo.bar!
Perhaps we could raise a particular exception, and document that
exception to describe the different issues that can cause it?
<div><p>The issue is slightly broader than just the cache stores though,
you'll have the same issues if you used:</p>
<p>$foo ||= Foo.first</p>
<h1>next request</h1>
<p>$foo.bar!</p>
<p>Perhaps we could raise a particular exception, and document that
exception to describe the different issues that can cause it?</p></div>
false
2009-03-09T04:23:07+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-03-09T04:23:11+00:00
141
Michael Koziarski
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
Sure. That's the issue with using global vars, and class vars have exactly the same issue.
I don't see what the big deal is here. Why aren't we just all using class level instance vars which only get initialized when they need to, like the following pastie:
http://gist.github.com/76130
This makes the thing lazy, and if the class magically goes away (via reloading through Module#remove_const), the data just gets reloaded the next time it is accessed.
Am I missing something here?
On another note, I like the exception idea, but I don't think there is any way you are going to be able to track absolutely everything that an object maybe holding on to, with the excepting of going to mod_ruby or invoking GC#each_object.
<div><p>Sure. That's the issue with using global vars, and class vars
have exactly the same issue.</p>
<p>I don't see what the big deal is here. Why aren't we just all
using class level instance vars which only get initialized when
they need to, like the following pastie:</p>
<p><a href="http://gist.github.com/76130">http://gist.github.com/76130</a></p>
<p>This makes the thing lazy, and if the class magically goes away
(via reloading through Module#remove_const), the data just gets
reloaded the next time it is accessed.</p>
<p>Am I missing something here?</p>
<p>On another note, I like the exception idea, but I don't think
there is any way you are going to be able to track absolutely
everything that an object maybe holding on to, with the excepting
of going to mod_ruby or invoking GC#each_object.</p></div>
false
2009-03-09T06:13:18+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-03-09T06:13:23+00:00
10212
Scott Taylor
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
Class variables behave fine (with respect to this bug) if they're
class vars on active record subclasses. e.g.
class User < AR::Base
cattr_accessor :most_popular
end
That's why making MemoryStore marshall the objects would be a
reasonable fix as beyond caching there's not many cases which can't be
more easily solved by slightly changing the design.
As for the exception, I was simply thinking about overriding
method_missing on the AR::Base subclass when we're calling
undef_method to just raise the exception immediately, irrespective of
the method or arguments.
<div><p>Class variables behave fine (with respect to this bug) if
they're class vars on active record subclasses. e.g.</p>
<p>class User < AR::Base cattr_accessor :most_popular end</p>
<p>That's why making MemoryStore marshall the objects would be a
reasonable fix as beyond caching there's not many cases which can't
be more easily solved by slightly changing the design.</p>
<p>As for the exception, I was simply thinking about overriding
method_missing on the AR::Base subclass when we're calling
undef_method to just raise the exception immediately, irrespective
of the method or arguments.</p></div>
false
2009-03-09T07:13:36+00:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-03-09T07:13:39+00:00
141
Michael Koziarski
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
So what has become the conventional way of dealing with this issue? To use Marshall? If so, does that imply having to create de/serializers too?
Apologies, I'm new (but have found myself hitting this problem)!
<div><p>So what has become the conventional way of dealing with this
issue? To use Marshall? If so, does that imply having to create
de/serializers too?</p>
<p>Apologies, I'm new (but have found myself hitting this
problem)!</p></div>
false
2009-04-06T16:22:20+01:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-04-06T16:22:25+01:00
53176
Shak
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
Just to make it clear for people who encounter the exception and end up reading about it here:
- The exception is raised when ActiveRecord::Base#skip_time_zone_conversion_for_attributes is being evaluated, but that is only a symptom, so fixes that address only that specific attribute do not really address the real issue.
The actual issue is caused by ActiveSupport::Dependencies not reloading classes declared in files that are explicitly required. This means you should avoid explicitly require'ing files and make your dependencies automatic, by naming and placing the files so that the Dependencies module will load them automatically.
As for persistence of AR objects, as Tom Lea explained, the issue is really the fact that classes are *redefined* on each request, as opposed to having the same classes being *reloaded* on each request. A persisted object will always refer to the initial Class instance it was created with, whereas objects created on subsequent requests will refer to new classes (even if they have the same name).
That being said, if I had to persist AR objects, I would stick to a persistence mechanism that only serializes its scalar (or rather: literal) attributes (i.e. String, Fixnum, etc.) and which assigns those values to a new AR instance that gets reinitialized on each request, but I would never hold on to an actual Class reference.
I have to admit I am not familiar Marshall or MemStore and maybe that's the way those work. If that's the case, then it should pose no problem to use them for persistence.
<div><p>Just to make it clear for people who encounter the exception and
end up reading about it here:</p>
<ul>
<li>The exception is raised when
ActiveRecord::Base#skip_time_zone_conversion_for_attributes is
being evaluated, but that is only a symptom, so fixes that address
only that specific attribute do not really address the real
issue.</li>
</ul>
<p>The actual issue is caused by ActiveSupport::Dependencies not
reloading classes declared in files that are explicitly required.
This means you should avoid explicitly require'ing files and make
your dependencies automatic, by naming and placing the files so
that the Dependencies module will load them automatically.</p>
<p>As for persistence of AR objects, as Tom Lea explained, the
issue is really the fact that classes are <em>redefined</em> on
each request, as opposed to having the same classes being
<em>reloaded</em> on each request. A persisted object will always
refer to the initial Class instance it was created with, whereas
objects created on subsequent requests will refer to new classes
(even if they have the same name).</p>
<p>That being said, if I had to persist AR objects, I would stick
to a persistence mechanism that only serializes its scalar (or
rather: literal) attributes (i.e. String, Fixnum, etc.) and which
assigns those values to a new AR instance that gets reinitialized
on each request, but I would never hold on to an actual Class
reference.</p>
<p>I have to admit I am not familiar Marshall or MemStore and maybe
that's the way those work. If that's the case, then it should pose
no problem to use them for persistence.</p></div>
false
2009-04-06T18:24:14+01:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-04-06T18:24:20+01:00
42669
C. Bedard
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
@Shak, @C. Bedard
If you must store between requests, Marshal it. If you would simply prefer it to be there between requests, stash it in your controller's class, or the model's class, these will be reloaded anyway. If you are using a cache store, and are hitting this issue, just don't use the memory store.
If you must marshal, don't worry, it's easy, everything works by 'magic' 99% of the time. Juts call Marshal.dump and Marshal.load as needed. Serialisation is handled for you, no need to define {,de}serializers, this is ruby, it uses its magic for good, not evil.
<div><p>@Shak, @C. Bedard If you must store between requests, Marshal
it. If you would simply prefer it to be there between requests,
stash it in your controller's class, or the model's class, these
will be reloaded anyway. If you are using a cache store, and are
hitting this issue, just don't use the memory store.</p>
<p>If you must marshal, don't worry, it's easy, everything works by
'magic' 99% of the time. Juts call Marshal.dump and Marshal.load as
needed. Serialisation is handled for you, no need to define
{,de}serializers, this is ruby, it uses its magic for good, not
evil.</p></div>
false
2009-04-06T20:24:12+01:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-04-06T20:24:21+01:00
28420
Tom Lea
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
Thanks for the tips - I don't want to turn this into a support thread but just for completion: I'm trying to persist a semi static look up table created from an RPC call - a prime candidate for caching using Rails.cache. For the moment I'm using memstore (this may change to memcached later).
Since my extended instance methods (the lookup is a hash of tableless AR objects) are being stripped I've marshalled (without any fancy coding) them and it all seems to be working rather well. Thanks for the pointers.
<div><p>Thanks for the tips - I don't want to turn this into a support
thread but just for completion: I'm trying to persist a semi static
look up table created from an RPC call - a prime candidate for
caching using Rails.cache. For the moment I'm using memstore (this
may change to memcached later).</p>
<p>Since my extended instance methods (the lookup is a hash of
tableless AR objects) are being stripped I've marshalled (without
any fancy coding) them and it all seems to be working rather well.
Thanks for the pointers.</p></div>
false
2009-04-06T20:48:45+01:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-04-06T20:48:52+01:00
53176
Shak
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
Note that you also see this error if you relate an AR model in a plugin to one that is not in a plugin. It's bad practice, yes, but it exposes this error condition as well.
<div><p>Note that you also see this error if you relate an AR model in a
plugin to one that is not in a plugin. It's bad practice, yes, but
it exposes this error condition as well.</p></div>
false
2009-04-08T00:34:30+01:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking it's children, just because it lost interest
2009-04-08T00:34:39+01:00
11769
jmoses
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
I'd just like to note that this bug is really prominent on Metals. Class data members et al collide into this bug and create a lot of hurt. (If I follow what's happening correctly, that is...)
Without workarounds, 2.3.2 Metals that hang on to things between requests are very hard to use in development mode as a result. You end up with some awkward calling conventions and/or a lot of Marshall stuff.
Please, Rails gods, find a fix for this. :)
<div><p>I'd just like to note that this bug is really prominent on
Metals. Class data members et al collide into this bug and create a
lot of hurt. (If I follow what's happening correctly, that
is...)</p>
<p>Without workarounds, 2.3.2 Metals that hang on to things between
requests are very hard to use in development mode as a result. You
end up with some awkward calling conventions and/or a lot of
Marshall stuff.</p>
<p>Please, Rails gods, find a fix for this. :)</p></div>
false
2009-04-10T21:52:11+01:00
28420
---
:title: AR::Base should not be nuking it's children, just because it lost interest
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking its children, just because it lost interest
2009-04-10T21:52:16+01:00
53098
maschnitz (at yahoo)
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
Just tried the patch against 2.3, and I can't seem to find any evidence of a difference in memory leakynes anymore.
Could someone (ideally @C. Bedard with he same app) try the patch against master to confirm, or prove me stupid? The existing patch applies clean.
Thanks
p.s. Thanks for the grammar fix maschnitz☺
<div><p>Just tried the patch against 2.3, and I can't seem to find any
evidence of a difference in memory leakynes anymore.</p>
<p>Could someone (ideally @C. Bedard with he same app) try the
patch against master to confirm, or prove me stupid? The existing
patch applies clean.</p>
<p>Thanks</p>
<p>p.s. Thanks for the grammar fix maschnitz☺</p></div>
false
2009-04-11T04:59:41+01:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking its children, just because it lost interest
2009-04-11T04:59:48+01:00
28420
Tom Lea
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
I saw this bug in an app that required some models from an initializer. The second page load would die. This patch kinda-sorta fixed it, but if anyone's seeing this bug and can't figure out why, check your initializers for a `require 'user'`
<div><p>I saw this bug in an app that required some models from an
initializer. The second page load would die. This patch kinda-sorta
fixed it, but if anyone's seeing this bug and can't figure out why,
check your initializers for a <code>require 'user'</code></p></div>
false
2009-08-13T01:22:01+01:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking its children, just because it lost interest
2009-08-13T01:22:08+01:00
13
court3nay
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
Guys, don't know if it helps, but we just found the similar issue to occur.
Having patched our Rails with the stuff you provided, we ran into the similar issue: we did something like
user.level.bar,
and sucked loudly, because belongs_to association (level on user) also used some class_inheritable_accessor (for scoping) and it also turned to become nil on and after 2nd FCKNG request.
The hint there is that our model, user, actually subclasses the model stored in the plugin. Do you have any hint on this?
<div><p>Guys, don't know if it helps, but we just found the similar
issue to occur.</p>
<p>Having patched our Rails with the stuff you provided, we ran
into the similar issue: we did something like</p>
<p>user.level.bar,</p>
<p>and sucked loudly, because belongs_to association (level on
user) also used some class_inheritable_accessor (for scoping) and
it also turned to become nil on and after 2nd FCKNG request.</p>
<p>The hint there is that our model, user, actually subclasses the
model stored in the plugin. Do you have any hint on this?</p></div>
false
2009-08-13T17:24:01+01:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking its children, just because it lost interest
2009-08-13T17:24:08+01:00
51446
mail2lf (at gmail)
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
Never mind the previous comment, found require in the environment.rb. Sorry for senseless note.
<div><p>Never mind the previous comment, found require in the
environment.rb. Sorry for senseless note.</p></div>
false
2009-08-14T13:51:06+01:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking its children, just because it lost interest
2009-08-14T13:51:13+01:00
51446
mail2lf (at gmail)
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
85
4
I'm facing a similar issue, and I think I may have found a use case that may help.
In two separate projects I'm working on, I have added an `attr_accessor` to the model for virtual attributes. The first is `data` and the second is `number`. Here are the implementations simplified:
@@@
class Forecast < ActiveRecord::Base
attr_accessor :data
end
class CreditCardProfile < ActiveRecord::Base
attr_accessor :number
end
@@@
There are used virtually when the object is initialised to hold data which will not be present when the object is saved to the database. In both cases, using instance variables such as `data` and `data=` have resulted in the following error:
>> credit_card_profile.save
NoMethodError: You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.include?
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/attribute_methods.rb:142:in `create_time_zone_conversion_attribute?'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/attribute_methods.rb:75:in `define_attribute_methods'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/attribute_methods.rb:71:in `each'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/attribute_methods.rb:71:in `define_attribute_methods'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/attribute_methods.rb:242:in `method_missing'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/transactions.rb:206:in `rollback_active_record_state!'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/transactions.rb:196:in `save'
from (irb):98
It looks as though this only affects models with virtual attributes such as these. Looking at line 142 for attribute_methods.rb, since `[:datestamp, :timestamp]` are already defined, I think its choking around the `skip_time_zone_conversion_for_attributes` method.
I hope this helps!
<div><p>I'm facing a similar issue, and I think I may have found a use
case that may help.</p>
<p>In two separate projects I'm working on, I have added an
<code>attr_accessor</code> to the model for virtual attributes. The
first is <code>data</code> and the second is <code>number</code>.
Here are the implementations simplified:</p>
<pre>
<code>class Forecast < ActiveRecord::Base
attr_accessor :data
end
class CreditCardProfile < ActiveRecord::Base
attr_accessor :number
end</code>
</pre>
<p>There are used virtually when the object is initialised to hold
data which will not be present when the object is saved to the
database. In both cases, using instance variables such as
<code>data</code> and <code>data=</code> have resulted in the
following error:</p>
<pre>
<code>>> credit_card_profile.save
NoMethodError: You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.include?
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/attribute_methods.rb:142:in `create_time_zone_conversion_attribute?'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/attribute_methods.rb:75:in `define_attribute_methods'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/attribute_methods.rb:71:in `each'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/attribute_methods.rb:71:in `define_attribute_methods'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/attribute_methods.rb:242:in `method_missing'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/transactions.rb:206:in `rollback_active_record_state!'
from /Library/Ruby/Gems/1.8/gems/activerecord-2.3.3/lib/active_record/transactions.rb:196:in `save'
from (irb):98</code>
</pre>
<p>It looks as though this only affects models with virtual
attributes such as these. Looking at line 142 for
attribute_methods.rb, since <code>[:datestamp, :timestamp]</code>
are already defined, I think its choking around the
<code>skip_time_zone_conversion_for_attributes</code> method.</p>
<p>I hope this helps!</p></div>
false
2009-09-08T19:02:10+01:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking its children, just because it lost interest
2009-09-08T19:02:16+01:00
27299
Josh Delsman
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
Jeremy Kemper
4
I ran in to this problem when moving some models in to an 'engine' plugin. It occurs when I try and access a 'belongs_to' association in either the view or console.
(eg. @document.author.name)
# /app/model/user.rb
class User
has_many :documents
end
# /app/vendor/qwerty/app/models/document.rb
class Document
belongs_to :author, :class_name => 'User', :foreign_key => 'author_id'
end
<div><p>I ran in to this problem when moving some models in to an
'engine' plugin. It occurs when I try and access a 'belongs_to'
association in either the view or console.</p>
<p>(eg. @document.author.name)</p>
<h1>/app/model/user.rb</h1>
<p>class User<br>
has_many :documents end</p>
<h1>/app/vendor/qwerty/app/models/document.rb</h1>
<p>class Document<br>
belongs_to :author, :class_name => 'User', :foreign_key =>
'author_id' end</p></div>
false
2009-09-23T19:08:12+01:00
28420
---
:assigned_user: 85
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking its children, just because it lost interest
2009-09-23T19:08:25+01:00
70786
Kris Leech
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
4
I have this issue when using acts_as_versioned in rails 2.3.4 (also previously in 2.3.2).
This works:
Profile.first.updater.login
This blows up on create_time_zone_conversion_attribute?:
Profile.first.versions.first.updater.login
Note that the version actually returns a Profile::Version, not Profile, which is a subclass of Profile.
Also, Profile.first.versions.first.updater returns just fine AND (with inspect) shows the 'login' field normally. But somehow calling .login on it breaks.
I added the config.active_record.default_timezone line and that no longer happens... on the *first* hit of the server. Instead, it gives this error:
time_ago_in_words Profile.first.version.first.updated_at
=> undefined method `abs' for Sat May 23 09:15:57 -0700 1970:Time
@ vendor/rails/actionpack/lib/action_view/helpers/date_helper.rb:62:in `distance_of_time_in_words'
Note that Profile.first.version.first.updated_at appears to work fine in all cases.
On subsequent hits, the create_time_zone_conversion_attribute? error happens again.
This behavior is identical between dev and production mode, and my cache_classes settings are normal (off for dev, on for prod).
<div><p>I have this issue when using acts_as_versioned in rails 2.3.4
(also previously in 2.3.2).</p>
<p>This works:<br>
Profile.first.updater.login<br>
This blows up on create_time_zone_conversion_attribute?:<br>
Profile.first.versions.first.updater.login</p>
<p>Note that the version actually returns a Profile::Version, not
Profile, which is a subclass of Profile.</p>
<p>Also, Profile.first.versions.first.updater returns just fine AND
(with inspect) shows the 'login' field normally. But somehow
calling .login on it breaks.</p>
<p>I added the config.active_record.default_timezone line and that
no longer happens... on the <em>first</em> hit of the server.
Instead, it gives this error:</p>
<p>time_ago_in_words Profile.first.version.first.updated_at<br>
=> undefined method <code>abs' for Sat May 23 09:15:57 -0700
1970:Time @
vendor/rails/actionpack/lib/action_view/helpers/date_helper.rb:62:in</code>distance_of_time_in_words'</p>
<p>Note that Profile.first.version.first.updated_at appears to work
fine in all cases.</p>
<p>On subsequent hits, the create_time_zone_conversion_attribute?
error happens again.</p>
<p>This behavior is identical between dev and production mode, and
my cache_classes settings are normal (off for dev, on for
prod).</p></div>
false
2009-10-22T05:13:22+01:00
28420
--- {}
9903
1339
arbase-should-not-be-nuking-its-children-just-because-it-lost-interest
0
8994
open
activerecord bug dependencies reload
AR::Base should not be nuking its children, just because it lost interest
2009-10-22T05:13:29+01:00
73743
Sai Emrys
Tom Lea
http://rails.lighthouseapp.com/projects/8994/tickets/1339
2.x
f836b795d298e32ff30bef2410ead136aefdfbdf
text/plain
2008-11-06T21:36:17+00:00
prevent_class_method_and_variable_nukeing_on_AR_reset_subclasses.diff
60054
1091
28420
http://rails.lighthouseapp.com/attachments/60054/prevent_class_method_and_variable_nukeing_on_AR_reset_subclasses.diff
4418fd01da11c3394a11782a506bcd47ff406199
text/plain
2009-01-06T19:13:49+00:00
AR_dev_mode_reloading.diff
75832
4355
42669
http://rails.lighthouseapp.com/attachments/75832/AR_dev_mode_reloading.diff
f60f28f39cb86b4552ecdb6ef5b0fc59a253b25f
application/zip
2009-01-08T05:36:24+00:00
lighthouse-ticket-1339.zip
76348
94161
42669
http://rails.lighthouseapp.com/attachments/76348/lighthouse-ticket-1339.zip
9ccdd2a6117907cdc6e101e41ca96f67952dbf8c
text/plain
2009-01-12T10:28:26+00:00
rebased-20090112-prevented-AR.reset_subclasses-from-killing-existing.patch
77318
1295
28420
http://rails.lighthouseapp.com/attachments/77318/rebased-20090112-prevented-AR.reset_subclasses-from-killing-existing.patch