Comment #0 by verylonglogin.reg — 2016-02-25T13:45:30Z
This program fails with OutOfMemoryError on 32-bit Windows with dmd 2.070.0:
---
import std.zlib;
void main() { for(;;) new ubyte[6_300_000]; }
---
Nasty thing about this bug is the more code your application have the more RAM it will require thus making in very difficult to track down as once you just remove any code from any function (the function you even never call) memory usage decreases. In my simple 5-file utility it was enough to allocate no more than around 1 MiB to get OOM error after few minutes of images processing.
I don't think the language is usable until this is fixed so marked as BLOCKER.
Comment #1 by dfj1esp02 — 2016-02-25T16:12:17Z
That's probably zlib's crc table: 2048 random pointers in bss. Does your application use zlib?
Comment #2 by verylonglogin.reg — 2016-02-25T19:14:12Z
(In reply to Sobirari Muhomori from comment #1)
> That's probably zlib's crc table: 2048 random pointers in bss.
So it looks like we actually can't use C libraries statically linked with D code as it will make GC almost useless.
> Does your application use zlib?
I have provided the whole test application in the description. As for my utility, yes it does use zlib.
Comment #3 by dfj1esp02 — 2016-02-26T10:04:30Z
Yes, if C library has lots of random numbers in .data and .bss sections, that will be a problem. We can try to put crc table into .rdata section and exclude .rdata from GC roots (if not already).
Comment #4 by dfj1esp02 — 2016-02-26T10:05:47Z
Though D can use this pattern too, so it's not only C library problem.
Comment #5 by dkorpel — 2019-06-07T22:06:45Z
*** Issue 18900 has been marked as a duplicate of this issue. ***
Comment #6 by r.sagitario — 2019-06-12T20:40:37Z
Use command line option "--DRT-scanDataSeg=precise" or embed it into the binary with rt_options.