[Issue 4358] Potential Memory Leaks in std.file.read() ?

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Jun 22 08:11:51 PDT 2010


http://d.puremagic.com/issues/show_bug.cgi?id=4358



--- Comment #6 from Leandro Lucarella <llucax at gmail.com> 2010-06-22 08:11:50 PDT ---
(In reply to comment #5)
> (In reply to comment #3)
> > Most likely, the GC _is_ working correctly. It's a conservative GC, and it
> > treats integers, floats, random binary data the same as actual pointers.
> 
> This is false. The GC only treats void[] as a potential source of pointers,
> which makes sense, really. int[], float[], char[], byte[] are *NOT* scanned for
> pointers. For a binary buffer that doesn't have pointers in it, you should
> probably use ubyte[]. If std.file.read() return void[], I'd say that
> std.file.read() is broken.

I should add that, even when ubyte[] is not scanned for pointers, you are right
about allocating big chunks of memory in the GC could lead to leaks, as the
probabilities of having a false pointer pointing to that chunk of data gets
really high.

There is another bug report (with a patch too, and from David Simcha too) that
helps with this problem: bug 2927. The idea is to add a new property to the GC
to mark a chunk as not having interior pointers. If you mark a chunk of memory
as not having interior pointers, the chances of a false pointer pointing to the
beginning of your memory chunk becomes *very* low.

It's a real shame that David's patches didn't get into druntime, as they are
very helpful avoiding this kind of issues.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list