[#15707] Schedule for the 1.8.7 release — "Akinori MUSHA" <knu@...>

Hi, developers,

21 messages 2008/03/01

[#15740] Copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>

Hi.

31 messages 2008/03/03
[#15742] Re: Copy-on-write friendly garbage collector — Yukihiro Matsumoto <matz@...> 2008/03/03

Hi,

[#15829] Re: Copy-on-write friendly garbage collector — Daniel DeLorme <dan-ml@...42.com> 2008/03/08

Yukihiro Matsumoto wrote:

[#15756] embedding Ruby 1.9.0 inside pthread — "Suraj Kurapati" <sunaku@...>

Hello,

18 messages 2008/03/03
[#15759] Re: embedding Ruby 1.9.0 inside pthread — Nobuyoshi Nakada <nobu@...> 2008/03/04

Hi,

[#15760] Re: embedding Ruby 1.9.0 inside pthread — Yukihiro Matsumoto <matz@...> 2008/03/04

Hi,

[#15762] Re: embedding Ruby 1.9.0 inside pthread — "Suraj N. Kurapati" <sunaku@...> 2008/03/04

Yukihiro Matsumoto wrote:

[#15783] Adding startup and shutdown to Test::Unit — Daniel Berger <Daniel.Berger@...>

Hi all,

15 messages 2008/03/04

[#15835] TimeoutError in core, timeouts for ConditionVariable#wait — MenTaLguY <mental@...>

I've been reworking JRuby's stdlib to improve performance and fix

10 messages 2008/03/09

[#15990] Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...>

Hi,

35 messages 2008/03/23
[#15991] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#15993] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/23

Hi Dave,

[#15997] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#16024] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

Hi Dave,

[#16025] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16026] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16027] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16029] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16030] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16031] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16032] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

On Wed, Mar 26, 2008 at 7:01 PM, Dave Thomas <dave@pragprog.com> wrote:

[#16033] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16041] Re: Recent changes in Range#step behavior — David Flanagan <david@...> 2008/03/26

Dave Thomas wrote:

Re: 1.8.6 memory leak?

From: "Stephen Sykes" <sdsykes@...>
Date: 2008-03-23 19:14:40 UTC
List: ruby-core #15995
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
>
>

In This Thread