digitalmars.D.learn - Memory leak in hello world

Thejaswi Puthraya (81/81) Jan 27 2014 I have a simple "Hello World" program (file named "tmp.d")

Rob (4/74) Jan 31 2014 This same question appears to have been answered here, but it's not

diahron (5/98) Jan 31 2014 The answer to your question is best explained by viewing this

Kagamin (8/22) Feb 01 2014 thread_attachThis creates an instance of Thread class for the

Kagamin (1/4) Feb 01 2014 oops, no, there's no malloc there.

Kagamin (2/2) Feb 01 2014 But still it must be allocated somehow, probably GC is

"Thejaswi Puthraya" <thejaswi.puthraya gmail.com> writes:

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.

Jan 27 2014

Rob <alanb ucora.com> writes:

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.

Jan 31 2014

"diahron" <diahron gmail.com> writes:

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.

Jan 31 2014

"Kagamin" <spam here.lot> writes:

On Monday, 27 January 2014 at 09:44:50 UTC, Thejaswi Puthraya 
wrote:
 ==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)

thread_attachThis creates an instance of Thread class for the 
main process thread during runtime initialization: 
https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L1792

 ==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)

synchronized statement in Thread.isDaemon allocates a critical 
section to lock: 
https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L809

Feb 01 2014

"Kagamin" <spam here.lot> writes:

 thread_attachThis creates an instance of Thread class for the 
 main process thread during runtime initialization: 
 https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L1792

oops, no, there's no malloc there.

Feb 01 2014

"Kagamin" <spam here.lot> writes:

But still it must be allocated somehow, probably GC is 
substituted for C heap.

Feb 01 2014

D Programming

C/C++ Programming

Other

digitalmars.D.learn - Memory leak in hello world