Hugh Sasse wrote:
> On Thu, 11 Oct 2007, M. Edward (Ed) Borasky wrote:
> 
>> M. Edward (Ed) Borasky wrote:
>>> I haven't had a chance to narrow this down in enough detail yet, but there
>>> may be a memory leak in ruby-1.8.6-p110. Specifically, what I'm doing is
>>>
>>> a. Gentoo Linux, amd64, gcc 4.2.1
>>> b. Compiling ruby-1.8.6-p110 with "-g -pg" (profiling and debugging options)
>>> c. Compiling the latest Ruby 1.9 from svn with full optimization
>>> (-march=athlon64, -O3)
>>> d. Running the built-in benchmark suite of Ruby 1.9 with the Ruby from step
>>> b. as the "matz" Ruby and the Ruby 1.9 from step c. as the Ruby 1.9
>>>
>>> When it gets to the "bm_loop_generate" benchmark, it hangs up in the 1.8.6
>>> run, and the Ruby interpreter grows arbitrarily large -- I killed it at 3 GB
>>> on my 4 GB machine.
>>>
>>> I'm going to do some more digging before I file a bug report, but I'm
>>> wondering if anyone else has seen anything like this. I'm in the process of
>>> running the same scenario on a 32-bit system, so I haven't ruled in or out
>>> 64-bit, gcc, etc. at this point.
>>>
>>>
>> Latest research:
>>
>> 1. It works fine on 32-bit.
>> 2. It works fine on 64-bit with debugging plus profiling *plus optimization*
>> (-g -pg -march=athlon64 -O3)
>> 3. So far the *only* failure mode is 64-bit with "-g -pg" only.
> 
> Is it worth trying -O2, -O1 ?

Eventually I might do that. I'll be testing the "-g" without "-pg" at 
some point, but I don't plan to try the other optimization levels. So if 
it goes away when "-pg" is removed, that pretty much nails the thing down.
>> So ... I'm going to call it a gcc (or gcc-gprof interface) problem and move
>> on. :)
> 
> A look through binutils-2.18/gprof/ChangeLog{,-2005} turns up nothing
> relevant to {pointer,gcc,memory,leak,athlon}, AFAICS.

It the profiling library start routine in binutils or in the C libraries?