digitalmars.D.bugs - [Issue 19322] New: A lot of memory is consumed and not freed to the
- d-bugmail puremagic.com (69/69) Oct 20 2018 https://issues.dlang.org/show_bug.cgi?id=19322
https://issues.dlang.org/show_bug.cgi?id=19322 Issue ID: 19322 Summary: A lot of memory is consumed and not freed to the system when Exception is formatted with stacktrace in debug 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); } } info("Done"); GC.collect(); GC.minimize(); readln(); } ``` 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 here). If tried with for example pretty large botan library: dependency "botan" version="~>1.12.10" 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