Created attachment 1041 [details] valgrind output I'm on Ubuntu x64, with the vanilla DMD .deb installed. I have attached the output of valgrind. The program that triggers valgrind to report the leak it is practically any that I run, including just a bare "void main() { }". It looks like _d_monitor_create is calloc'ing 72 bytes of memory that get "definitely lost" according to valgrind.
Created attachment 1185 [details] Valgrind report as of 2.061 I ran Valgrind on the same "test program": void main(){} The end result is that three more leaks have snuck in since Oct. 2011.
Adding to this bugreport - I compiled .d file with "void main() { }" and after running it Valgrind reports two memory leaks as seen below: ==11378== Memcheck, a memory error detector ==11378== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==11378== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==11378== Command: ./main ==11378== ==11378== ==11378== HEAP SUMMARY: ==11378== in use at exit: 88 bytes in 2 blocks ==11378== total heap usage: 29 allocs, 27 frees, 53,320 bytes allocated ==11378== ==11378== 16 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==11378== at 0x4C2ABA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11378== by 0x4248B3: _D2rt5tlsgc4initFZPv (tlsgc.d:34) ==11378== by 0x40DD67: thread_attachThis (.:1959) ==11378== by 0x40DBFF: thread_init (thread.d:1897) ==11378== by 0x416085: gc_init (proxy.d:129) ==11378== by 0x4040D4: rt_init (dmain2.d:164) ==11378== by 0x4048E0: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv (dmain2.d:399) ==11378== by 0x404878: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv (dmain2.d:375) ==11378== by 0x4047C7: _d_run_main (dmain2.d:408) ==11378== by 0x401DD7: main (.:3) ==11378== ==11378== 72 bytes in 1 blocks are definitely lost in loss record 2 of 2 ==11378== at 0x4C2CC90: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11378== by 0x424BAF: _d_monitor_create (monitor_.d:222) ==11378== by 0x414F8B: _d_monitorenter (object_.d:1860) ==11378== by 0x40D2BC: _D4core6thread6Thread8isDaemonMFNdZb (thread.d:829) ==11378== by 0x40DEE2: _D4core6thread14thread_joinAllUZ14__foreachbody1MFKC4core6thread6ThreadZi (thread.d:2114) ==11378== by 0x40D58F: _D4core6thread6Thread7opApplyFMDFKC4core6thread6ThreadZiZi (thread.d:1187) ==11378== by 0x40DE62: thread_joinAll (thread.d:2107) ==11378== by 0x40423D: rt_term (dmain2.d:191) ==11378== by 0x404926: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv (dmain2.d:404) ==11378== by 0x404878: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv (dmain2.d:375) ==11378== by 0x4047C7: _d_run_main (dmain2.d:408) ==11378== by 0x401DD7: main (.:3) ==11378== ==11378== LEAK SUMMARY: ==11378== definitely lost: 88 bytes in 2 blocks ==11378== indirectly lost: 0 bytes in 0 blocks ==11378== possibly lost: 0 bytes in 0 blocks ==11378== still reachable: 0 bytes in 0 blocks ==11378== suppressed: 0 bytes in 0 blocks ==11378== ==11378== For counts of detected and suppressed errors, rerun with: -v ==11378== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) I'm very new to D but I suspect these memory leaks are related to the threads module startup/shutdown. If anyone want's to point me into the right direction to tackle this bug I would be glad to help.
This PR fixes the issue: https://github.com/dlang/druntime/pull/1557 But needs some review from more experienced members. Regards, Giles
*** This issue has been marked as a duplicate of issue 17377 ***