www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 19322] New: A lot of memory is consumed and not freed to the


          Issue ID: 19322
           Summary: A lot of memory is consumed and not freed to the
                    system when Exception is formatted with stacktrace in
           Product: D
           Version: D2
          Hardware: x86_64
                OS: Linux
            Status: NEW
          Severity: regression
          Priority: P1
         Component: druntime
          Assignee: nobody puremagic.com
          Reporter: chalucha gmail.com

Original issue filed in vibe-d: https://github.com/vibe-d/vibe.d/issues/2221

Test code:

/+ dub.sdl:
        name "memleak"
        dependency "vibe-d:core" version="~>0.8.4"
        subConfiguration "vibe-d:core" "libevent"

import core.memory;
import std.stdio;
import std.experimental.logger;

import vibe.core.core; // comment this out to behave normally

void main()
        foreach (i; 0..1000)
                try throw new Exception("some message");
                catch (Exception ex)
                        errorf("Error: %s", ex);
                        //errorf("Error: %s", ex.msg);


Can be run with: dub --single sample.d

If I run this with dmd >= 2.081.0 the process is almost 500MB in memory.
GC.collect() and GC.minimize() doesn't matter.

If run with new vibe-core it's somewhat better at about 400MB in memory.

When just exception message is logged, process is at 6MB - what a difference.
Same when run with dmd-2.080.1 or without vibe-d.

Tested on fedora 28 x86_64 with multiple dmd versions and vibe-d-0.8.4.
Tested also on Ubuntu 18.04.1 x86_64

I tried to bisect this using digger with:

bad = https://github.com/dlang/phobos/pull/6700
good = https://github.com/dlang/phobos/pull/4941

And the winner seems to be: https://github.com/dlang/druntime/pull/2169
And due to it's change context it seems to be really connected with this even
though it should affect only OSX.

dmd --profile=gc and valgrind tools doesn't seems to lead anywhere.

What I've found after all is that it is unrelated to vibe-d (so I moved it

If tried with for example pretty large botan library: dependency "botan"

Resulted process memory (VmRSS) is much larger. So it seems to be some problem
with size of the included libraries and probably some memory fragmentation when
building the stacktrace?

It's ok in release build.

Oct 20 2018