Backport #1223: Memory leak reintroduced in 1.8.6 branch?

• Status: Closed
• Assignee: shyouhei (Shyouhei Urabe)

[spatulasnout (B Kelly)]

=begin
In early 2008, there were some 1.8.6 versions prior to p279 which exhibited severe memory leaks. See:

[ruby-core:17613] Re: [Ruby 1.8 - Bug #216] Memory leaks in 1.8.6p230 and p238

I say "prior to p279" because p279 happens to be the version I have been using since then which has had an extremely stable memory profile.

This morning when upgrading a server I also tried upgrading ruby 1.8.6 from p279 to the current p355.

The server has about 200 long running ruby processes, which on p279 can run for months with a stable memory profile.

After switching to p355 I could watch the memory drain away in real-time. I started with over 1GB free, and finally killed them when it got down to about 65M free. These are values from the "+/- buffers/cache" line from the free command in linux, printed at 5 second intervals, right before I killed the processes:

    used       free
 3959084     104360
 3963336     100108
 3969248      94196
 3974132      89312
 3977016      86428
 3981824      81620
 3983472      79972
 3988388      75056
 3991796      71648
 3994120      69324
 3996916      66528
 3997432      66012

After I swapped the old p279 binaries back in (libruby.so.1.8.6, libruby-static.a), the memory usage is once again stable.

Here are the svn revision numbers for the p279 vs. p355 builds I was using:

svn revision 19759 - ruby 1.8.6 (2008-07-17 patchlevel 279) [x86_64-linux]

svn revision 22671 - ruby 1.8.6 (2009-02-25 patchlevel 355) [x86_64-linux]

Regards,
=end

[oblomov (Giuseppe Bilotta)]

=begin
On Sat, Feb 28, 2009 at 1:33 AM, B Kelly [e-mail] wrote:

Bug #1223: Memory leak reintroduced in 1.8.6 branch?
http://redmine.ruby-lang.org/issues/show/1223

Author: B Kelly
Status: Open, Priority: Normal
Category: core, Target version: Ruby 1.8.6
ruby -v: ruby 1.8.6 (2009-02-25 patchlevel 355) [x86_64-linux]

In early 2008, there were some 1.8.6 versions prior to p279 which exhibited severe memory leaks. See:

[ruby-core:17613] Re: [Ruby 1.8 - Bug #216] Memory leaks in 1.8.6p230 and p238

I say "prior to p279" because p279 happens to be the version I have been using since then which has had an extremely stable memory profile.

This morning when upgrading a server I also tried upgrading ruby 1.8.6 from p279 to the current p355.

The server has about 200 long running ruby processes, which on p279 can run for months with a stable memory profile.

After switching to p355 I could watch the memory drain away in real-time.  I started with over 1GB free, and finally killed them when it got down to about 65M free.  These are values from the "+/- buffers/cache" line from the free command in linux, printed at 5 second intervals, right before I killed the processes:

[snip]

After I swapped the old p279 binaries back in (libruby.so.1.8.6, libruby-static.a), the memory usage is once again stable.

Here are the svn revision numbers for the p279 vs. p355 builds I was using:

 svn revision 19759 - ruby 1.8.6 (2008-07-17 patchlevel 279) [x86_64-linux]

 svn revision 22671 - ruby 1.8.6 (2009-02-25 patchlevel 355) [x86_64-linux]

If you have some time, you could try bisecting the changes betweeen
p279 and p355 to find the patch that introduced the problem. The
process runs like this:

good: p279, bad: p355

checkout p317

if it's good, bisect p317 -- p355, if it's bad, bisect p279 -- p317

repeat until good and bad are consecutive. This means that the leak
was most probably introduced in the bad commit you obtained last.

Since 355-279 = 76, it should take you 7 bisections step to identify
the culprit commit.

[BTW, one point in favour of migrating ruby's development to git would
be the built-in 'git bisect' feature that does just that .. if the
check for good/bad can be automated, it can even be automated to do
the entire bisection process automatically until the first culprit is
found]

--
Giuseppe "Oblomov" Bilotta

=end

[spatulasnout (B Kelly)]

=begin
I'll give it a shot. I have about a 24 hour window to try this...
I can't try it on the production server, but the old server from
which I just upgraded will remain in existence through tomorrow,
Feb 28.

You mention:

good: p279, bad: p355

checkout p317

How does one go about checking out a particular patchlevel by
number?

Are they tagged in svn somehow? Or should I just bisect the
svn revision number? (19759..22671)

=end

[spatulasnout (B Kelly)]

=begin

From: "Tanaka Akira" [e-mail]
[...]

So the problem is caused by 1.8.6p296, which ChangeLog is follows.

Ahh... thank you!! :D

I had begun bisecting, but it was very slow starting and
stopping those 200 servers. I had gotten as far as:

[good] revision 21215 - p287

--> next... ?

[bad] revision 21943 - p316

[bad] revision 22671 - p355

Regards,

Bill

=end

[shyouhei (Shyouhei Urabe)]

• Assignee set to nobu (Nobuyoshi Nakada)

=begin

=end

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

=begin
Applied in changeset r22882.
=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Closed to Open
• Assignee changed from nobu (Nobuyoshi Nakada) to shyouhei (Shyouhei Urabe)

=begin

=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Closed

=begin
Applied in changeset r23079.
=end