Bug #12954: valgrind shows memory leaks

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: 2.2.5p319
• Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN

[bmwiedemann (Bernhard M. Wiedemann)]

I found that ruby itself is leaking plenty memory
in ruby2.2, ruby2.1 and ruby1.9
The only version without such leakage was ruby1.8.

Steps To Reproduce on openSUSE Tumbleweed:
zypper mr -e repo-debug
zypper in --no-recommends valgrind libruby2_2-2_2-debuginfo
valgrind --log-file=/tmp/valgrind-ruby.txt --show-leak-kinds=definite
--leak-check=full /usr/bin/ruby -e ''

Actual Results:
/tmp/valgrind-ruby.txt shows 820KB leaked:
definitely lost: 223,845 bytes in 2,064 blocks
indirectly lost: 599,241 bytes in 11,712 blocks

It is less when running with --disable-gems but still existing.
And when adding a 'require "chef"' line, it goes above 6MB leaked.

[shevegen (Robert A. Heiler)]

I am not sure how easy it is for the ruby core team to reproduce it.

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Feedback

It's intentional that many objects (classes, methods, etc) are not freed.
Probably it's better to tell valgrind not to report such things.
Patches are welcome.

[hsbt (Hiroshi SHIBATA)]

• File valgrind-ruby.txt valgrind-ruby.txt added

Attached results of valgrind on openSUSE 13.2 and Ruby 2.1 package.

[normalperson (Eric Wong)]

[e-mail] wrote:

It's intentional that many objects (classes, methods, etc) are not freed.
Probably it's better to tell valgrind not to report such things.
Patches are welcome.

100% agreed, valgrind suppression files are preferred.

free() calls are slow, it is typical for free() to be slower
than {m,c,re}alloc() functions); this slows down the runtime
of short-lived scripts.

In fact, I've wanted to disable memory release during VM exit to
speed up short-lived scripts, but haven't gotten around to it...

[jeremyevans0 (Jeremy Evans)]

• Status changed from Feedback to Closed