From: Giuseppe Bilotta <giuseppe.bilotta@...>
Date: 2009-02-28T09:53:03+09:00
Subject: [ruby-core:22579] Re: [Bug #1223] Memory leak reintroduced in 1.8.6 	branch?

On Sat, Feb 28, 2009 at 1:33 AM, B Kelly <redmine@ruby-lang.org> 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