The problem with the D GC

Miles _______ at _______.____
Mon Jan 8 12:40:09 PST 2007


Oskar Linde wrote:
> After having fought a while with D programs with runaway memory leaks,
> I've unfortunately had to come to the conclusion that the D GC is not
> ready for production use. The problem is what I'd call "spurious
> pointers". That is random data (strings, numbers, image data, audio or
> whatever) appearing to the GC to be full of pointers to all over the
> memory space.

Some time ago I had the exact same problem, and I tried to convince
Walter of how bad this problem is. Others have said the same thing
before you and me. To Walter, "in practice, all integers vary from 0 to
100" or something like that, implying that the problem does not exist in
fact or is not relevant.

I should also mention that this is considered a serious security issue,
on the same class of the QuickSort algorithm.

For those not aware of secure programming practices: using QuickSort to
sort data input by a remote user is considered a bad programming
practice, because although QuickSort is O(n*log(n)) on average, there is
a set of input data that makes the algorithm O(n^2). Knowing the
implementation, an attacker may feed the application with carefully
crafted data that exploits this weakness.

In the D case, knowing how data are laid on memory, it is easy for a
remote attacker to feed data that, read as pointers, would point to
large (and otherwise temporary) blocks of data, making them leak. Stack
base randomization and other similar techniques helps preventing this,
but IMO, just hides the problem.

Another problem in current GC implementation, IMO, is that memory space
once allocated is never given back to the OS when disposed. What makes
this worse is that it is common for programs to use a big amount of
memory during initialization (like parsing XML data files), and never
use it again. Again, Walter already knows of this and doesn't think it
is a problem.



More information about the Digitalmars-d mailing list