https://issues.dlang.org/show_bug.cgi?id=17377
Issue ID: 17377 Summary: Empty D program is not valgrind clean Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: issues.dl...@jmdavisprog.com 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. --