Bug 17377 – Empty D program is not valgrind clean

When this program import std.stdio; void main() { } is run through valgrind --leak-check=full it shows that we're leaking memory: ==8668== Memcheck, a memory error detector ==8668== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==8668== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info ==8668== Command: ./empty ==8668== ==8668== ==8668== HEAP SUMMARY: ==8668== in use at exit: 88 bytes in 2 blocks ==8668== total heap usage: 101 allocs, 99 frees, 49,704 bytes allocated ==8668== ==8668== 16 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==8668== at 0x4C2CB3F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8668== by 0x15D0DD: _D2rt5tlsgc4initFNbNiZPv (in /home/jmdavis/empty) ==8668== by 0x157F51: thread_attachThis (in /home/jmdavis/empty) ==8668== by 0x157DDA: thread_init (in /home/jmdavis/empty) ==8668== by 0x144464: gc_init (in /home/jmdavis/empty) ==8668== by 0x13D437: rt_init (in /home/jmdavis/empty) ==8668== by 0x13A3C9: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFNlZv (in /home/jmdavis/empty) ==8668== by 0x13A36B: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFNlMDFZvZv (in /home/jmdavis/empty) ==8668== by 0x13A2DB: _d_run_main (in /home/jmdavis/empty) ==8668== by 0x13A0F7: main (in /home/jmdavis/empty) ==8668== ==8668== 72 bytes in 1 blocks are definitely lost in loss record 2 of 2 ==8668== at 0x4C2EB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8668== by 0x15CFFF: _D2rt8monitor_13ensureMonitorFNbC6ObjectZPOS2rt8monitor_7Monitor (in /home/jmdavis/empty) ==8668== by 0x15CF5E: _d_monitorenter (in /home/jmdavis/empty) ==8668== by 0x157B6C: _D4core6thread6Thread8isDaemonMFNdNiNfZb (in /home/jmdavis/empty) ==8668== by 0x143EDE: thread_joinAll (in /home/jmdavis/empty) ==8668== by 0x13D4E4: rt_term (in /home/jmdavis/empty) ==8668== by 0x13A3F9: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFNlZv (in /home/jmdavis/empty) ==8668== by 0x13A36B: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFNlMDFZvZv (in /home/jmdavis/empty) ==8668== by 0x13A2DB: _d_run_main (in /home/jmdavis/empty) ==8668== by 0x13A0F7: main (in /home/jmdavis/empty) ==8668== ==8668== LEAK SUMMARY: ==8668== definitely lost: 88 bytes in 2 blocks ==8668== indirectly lost: 0 bytes in 0 blocks ==8668== possibly lost: 0 bytes in 0 blocks ==8668== still reachable: 0 bytes in 0 blocks ==8668== suppressed: 0 bytes in 0 blocks ==8668== ==8668== For counts of detected and suppressed errors, rerun with: -v ==8668== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) There's a good chance that this really doesn't matter normally, but if not even an empty program is valgrind clean, then it's likely to be problematic to verify that we don't have memory problems when using allocators or integrating with C/C++. It would not surprise me if we need a way to run druntime that indicates that we're running valgrind so that it does cleanup that it doesn't normally do (e.g. force the GC to clean up everything on shutdown, which it normally wouldn't), but I don't know. Either way, valgrind indicates that we're currently leaking with an empty main.

There's a PR that should fix it, https://github.com/dlang/druntime/pull/1557, the status is unclear.

Issue got fixed by https://github.com/dlang/druntime/pull/1857 or ? $ dmd --version DMD64 D Compiler v2.078.1 Copyright (c) 1999-2017 by The D Language Foundation written by Walter Bright $ valgrind --leak-check=full ./test_17377 ==13243== Memcheck, a memory error detector ==13243== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==13243== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==13243== Command: ./test_17377 ==13243== ==13243== ==13243== HEAP SUMMARY: ==13243== in use at exit: 0 bytes in 0 blocks ==13243== total heap usage: 95 allocs, 95 frees, 49,028 bytes allocated ==13243== ==13243== All heap blocks were freed -- no leaks are possible ==13243== ==13243== For counts of detected and suppressed errors, rerun with: -v ==13243== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

*** Issue 6830 has been marked as a duplicate of this issue. ***