Created attachment 922 [details] Very simple patch against D1's gcx.d which throws OutofMemory when allocating during a GC run D's current garbage collector is completely unprepared to handle an allocation which is called by a finalizer. Such an allocation puts D's GC into an inconsistent state, which ultimately leads to memory corruption. The GC should either forbid allocating in destructors (by throwing an exception), or properly support it (which may be non-trivial). If the first solution is chosen, it should be noted that there are instances of allocations in destructors in Phobos as well (such as std.zlib).
Created attachment 971 [details] Memory corruption test
Created attachment 972 [details] Naive test for disallowing GC interaction after a finalizer exception
https://github.com/D-Programming-Language/phobos/pull/44 https://github.com/D-Programming-Language/druntime/pull/16
Fixed here: https://github.com/D-Programming-Language/phobos/pull/44 Does that take care of D1 too?
(In reply to comment #4) > Fixed here: https://github.com/D-Programming-Language/phobos/pull/44 Does that > take care of D1 too? The Phobos pull request is for D1, the druntime pull request is for D2. Thanks!
Note that this patch will cause all successive allocations by the process to generate an OOME, since gcx.running will be true forever. This may be a good stopgap fix, but ultimately the GC has to support allocations inside a finalizer. The best approach is probably to effectively disable the GC when it's running so an allocating finalizer would simply create a new Pool if no memory was available. It looks like the collect routine still needs to be rewritten with this in mind, however.
(In reply to comment #6) > Note that this patch will cause all successive allocations by the process to > generate an OOME, since gcx.running will be true forever. Yes, this is by design until someone comes up with something better.