Memory leak in hello world

[diahron]

On Friday, 31 January 2014 at 21:00:38 UTC, Rob wrote:
> 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.

The answer to your question is best explained by viewing this 
video, located at: http://www.youtube.com/watch?v=RlVpPstLPEc. 
Fastfoward into the video about 13 to 15 minutes and the 
answer(s) start. Hope that helps.