Bug #12954
closedvalgrind shows memory leaks
Description
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.
Files
Updated by shevegen (Robert A. Heiler) almost 8 years ago
I am not sure how easy it is for the ruby core team to reproduce it.
Updated by nobu (Nobuyoshi Nakada) almost 8 years ago
- 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.
Updated by hsbt (Hiroshi SHIBATA) almost 8 years ago
- File valgrind-ruby.txt valgrind-ruby.txt added
Attached results of valgrind on openSUSE 13.2 and Ruby 2.1 package.
Updated by normalperson (Eric Wong) almost 8 years ago
nobu@ruby-lang.org 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...
Updated by jeremyevans0 (Jeremy Evans) over 5 years ago
- Status changed from Feedback to Closed