By the way, I also have a valgrind trace of this leak.  Running with
5000.times (not 15000 - takes too long) gives this:

==18706== 217,988,864 bytes in 499,985 blocks are
definitely lost in loss record 6 of 6
==18706==    at 0x4A05AF7: realloc (vg_replace_malloc.c:306)
==18706==    by 0x432398: ruby_xrealloc (gc.c:151)
==18706==    by 0x465E9C: local_append (parse.y:5649)
==18706==    by 0x465F64: local_cnt (parse.y:5667)
==18706==    by 0x4646AC: assignable (parse.y:4902)
==18706==    by 0x458E80: ruby_yyparse (parse.y:844)
==18706==    by 0x45E5F4: yycompile (parse.y:2606)
==18706==    by 0x45E8F4: rb_compile_string (parse.y:2676)
==18706==    by 0x41DDF3: compile (eval.c:6412)
==18706==    by 0x41E289: eval (eval.c:6493)
==18706==    by 0x41E817: rb_f_eval (eval.c:6611)
==18706==    by 0x41C765: call_cfunc (eval.c:5700)
==18706==    by 0x41BB04: rb_call0 (eval.c:5856)
==18706==    by 0x41D291: rb_call (eval.c:6103)
==18706==    by 0x415182: rb_eval (eval.c:3494)

The memory used to expand the local variable table (when doing an
eval) is never freed by the look of it.  But the question is, where
should it be freed?  That is something that I hope someone who
understands the parser better than I do can answer.

Regards,
Stephen

On Sat, Mar 22, 2008 at 6:10 PM, Stephen Sykes <sdsykes / gmail.com> wrote:
>
> Hi,
>
>  Testing with ruby 1.8.6 (2008-03-03 patchlevel 114) [x86_64-linux], this:
>
>  def grow
>   for i in 1..100
>     eval "b#{i}=1"
>   end
>  end
>  15000.times {grow}
>
>  ...seems to cause linear process growth with according to how many
>  assignments are done.
>
>  Is this a bug or is it in some way (that I didn't notice) explicable?
>
>  regards,
>  Stephen Sykes
>
>