Memory leak in hello world

[Rob]

This same question appears to have been answered here, but it's not 
really conclusive
http://stackoverflow.com/questions/14802212/memory-leak-in-minimal-d-program


On 2014-01-27 01:44, Thejaswi Puthraya wrote:
> I have a simple "Hello World" program (file named "tmp.d") written in D
>
> import std.stdio;
>
> void main() {
> printf("Hello World\n");
> }
>
> I successfully compiled the above program with the DMD64 D compiler
> v2.064 on linux x86_64 (libc 2.18 just in case required). But valgrind
> reports memory leaks while running the program.
>
> valgrind --leak-check=full ./tmp
> ==11356== Memcheck, a memory error detector
> ==11356== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==11356== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
> ==11356== Command: ./tmp
> ==11356==
> Hello World
> ==11356==
> ==11356== HEAP SUMMARY:
> ==11356== in use at exit: 88 bytes in 2 blocks
> ==11356== total heap usage: 25 allocs, 23 frees, 53,016 bytes allocated
> ==11356==
> ==11356== 16 bytes in 1 blocks are definitely lost in loss record 1 of 2
> ==11356== at 0x4A0645D: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==11356== by 0x43E366: thread_attachThis (in /home/theju/tmp)
> ==11356== by 0x43E1F6: thread_init (in /home/theju/tmp)
> ==11356== by 0x4361D8: gc_init (in /home/theju/tmp)
> ==11356== by 0x42E627: rt_init (in /home/theju/tmp)
> ==11356== by 0x426CD5:
> _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi6runAllMFZv (in /home/theju/tmp)
> ==11356== by 0x426C91:
> _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi7tryExecMFMDFZvZv (in
> /home/theju/tmp)
> ==11356== by 0x426C12: _d_run_main (in /home/theju/tmp)
> ==11356== by 0x426606: main (in /home/theju/tmp)
> ==11356==
> ==11356== 72 bytes in 1 blocks are definitely lost in loss record 2 of 2
> ==11356== at 0x4A081D4: calloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==11356== by 0x444A95: _d_monitor_create (in /home/theju/tmp)
> ==11356== by 0x43A181: _d_monitorenter (in /home/theju/tmp)
> ==11356== by 0x43DF19: _D4core6thread6Thread8isDaemonMFNdZb (in
> /home/theju/tmp)
> ==11356== by 0x435AAB:
> _D4core6thread14thread_joinAllUZv14__foreachbody1MFKC4core6thread6ThreadZi
> (in /home/theju/tmp)
> ==11356== by 0x43DFB8:
> _D4core6thread6Thread7opApplyFMDFKC4core6thread6ThreadZiZi (in
> /home/theju/tmp)
> ==11356== by 0x435A24: thread_joinAll (in /home/theju/tmp)
> ==11356== by 0x42E6BC: rt_term (in /home/theju/tmp)
> ==11356== by 0x426D05:
> _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi6runAllMFZv (in /home/theju/tmp)
> ==11356== by 0x426C91:
> _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi7tryExecMFMDFZvZv (in
> /home/theju/tmp)
> ==11356== by 0x426C12: _d_run_main (in /home/theju/tmp)
> ==11356== by 0x426606: main (in /home/theju/tmp)
> ==11356==
> ==11356== LEAK SUMMARY:
> ==11356== definitely lost: 88 bytes in 2 blocks
> ==11356== indirectly lost: 0 bytes in 0 blocks
> ==11356== possibly lost: 0 bytes in 0 blocks
> ==11356== still reachable: 0 bytes in 0 blocks
> ==11356== suppressed: 0 bytes in 0 blocks
> ==11356==
> ==11356== For counts of detected and suppressed errors, rerun with: -v
> ==11356== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)
>
> One IRC user on #d seemed to suggest that this is a long term GC issue.
> Is this right? A little more explanation about what is happening will be
> very helpful.