Menu
Search

Forums

Forum Index

Thread overview
Memory leak in hello world
Jan 27, 2014
Thejaswi Puthraya
Jan 31, 2014
Rob
Jan 31, 2014
diahron
Feb 01, 2014
Kagamin
Feb 01, 2014
Kagamin
Feb 01, 2014
Kagamin
January 27, 2014
Gravatar of Thejaswi PuthrayaPosted by Thejaswi PuthrayaReply
Thejaswi Puthraya
Gravatar of Thejaswi Puthraya


Reply
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.
January 31, 2014
Gravatar of RobPosted by Rob
in reply to Thejaswi Puthraya		Reply
Rob
Gravatar of Rob
Posted in reply to Thejaswi Puthraya


Reply
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.
January 31, 2014
Gravatar of diahronPosted by diahron
in reply to Rob		Reply
diahron
Gravatar of diahron
Posted in reply to Rob


Reply
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.
February 01, 2014
Gravatar of KagaminPosted by Kagamin
in reply to Thejaswi Puthraya		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to Thejaswi Puthraya


Reply
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
February 01, 2014
Gravatar of KagaminPosted by Kagamin
in reply to Kagamin		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to Kagamin


Reply
> 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.
February 01, 2014
Gravatar of KagaminPosted by Kagamin
in reply to Kagamin		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to Kagamin


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