Backport #2009

File.open memory leak

Added by Sven Engelhardt over 2 years ago. Updated 9 months ago.

[ruby-core:25173]
Status:Closed Start date:08/28/2009
Priority:Normal Due date:
Assignee:Kirk Haines % Done:

100%

Category:-
Target version:-

Description

File.open looses 28 bytes of memory on each call:
(p72 releases the memory correctly, p160, p174 dont)

big% cat rbtest                                                             

20000.times do

File.open("/etc/passwd","r") { |f|
	f.each { |l|
		l.chomp!
	}
}

end

big% valgrind --leak-check=full /opt/valgrind/ruby/1.8.7-174/bin/ruby rbtest
==15828== Memcheck, a memory error detector.
==15828== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==15828== Using LibVEX rev 1804, a library for dynamic binary translation.
==15828== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==15828== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
==15828== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==15828== For more details, rerun with: -v
==15828== 
==15828== 
==15828== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 21 from 1)
==15828== malloc/free: in use at exit: 1,334,734 bytes in 31,012 blocks.
==15828== malloc/free: 787,948 allocs, 756,936 frees, 101,067,560 bytes allocated.
==15828== For counts of detected errors, rerun with: -v
==15828== searching for pointers to 31,012 not-freed blocks.
==15828== checked 824,216 bytes.
==15828== 
==15828== 557,312 (555,744 direct, 1,568 indirect) bytes in 19,848 blocks are definitely lost in loss record 5 of 6
==15828==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==15828==    by 0x80745B6: ruby_xmalloc (gc.c:158)
==15828==    by 0x807D02C: rb_file_open_internal (io.c:2993)
==15828==    by 0x807D1A5: rb_file_initialize (io.c:3422)
==15828==    by 0x8058053: call_cfunc (eval.c:5771)
==15828==    by 0x8061F92: rb_call0 (eval.c:5926)
==15828==    by 0x8062240: rb_call (eval.c:6173)
==15828==    by 0x80624F7: rb_obj_call_init (eval.c:7809)
==15828==    by 0x808AA99: rb_class_new_instance (object.c:1644)
==15828==    by 0x8079AEF: rb_io_s_open (io.c:3446)
==15828==    by 0x8058053: call_cfunc (eval.c:5771)
==15828==    by 0x8061F92: rb_call0 (eval.c:5926)
==15828== 
==15828== LEAK SUMMARY:
==15828==    definitely lost: 555,744 bytes in 19,848 blocks.
==15828==    indirectly lost: 1,568 bytes in 56 blocks.
==15828==      possibly lost: 0 bytes in 0 blocks.
==15828==    still reachable: 777,422 bytes in 11,108 blocks.
==15828==         suppressed: 0 bytes in 0 blocks.
==15828== Reachable blocks (those to which a pointer was found) are not shown.
==15828== To see them, rerun with: --leak-check=full --show-reachable=yes

Associated revisions

Revision 25181
Added by matz over 2 years ago

* io.c (rb_io_fptr_finalize): free fptr to avoid memory leaks. fixed: #2009 [ruby-core:25173] [ruby-dev:39410]

Revision 26457
Added by wyhaines about 2 years ago

Backport #2009 [ruby-core:25173]; (rb_io_fptr_finalize): free fptr to avoid memory leaks. My brain got stuck in a bad pattern, and I kept adding new items under the first record for the day. They are all broken out into their own entries like they should be, now, with timestamps pulled from the SVN log.

History

Updated by Yukihiro Matsumoto over 2 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100
Applied in changeset r25181.

Updated by Shyouhei Urabe about 2 years ago

  • Status changed from Closed to Assigned
  • Assignee set to Kirk Haines
According to my valgrind output 1.8.6 also has this memory leak.

Updated by Kirk Haines about 2 years ago

  • Status changed from Assigned to Closed
This issue was solved with changeset r26457.
Sven, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

Also available in: Atom PDF