Valgrind appears to find some leftover memory in _D2rt6dmain211_d_run_main... when I scan for potential leaks.
$ valgrind --error-exitcode=1 --leak-check=full --show-leak-kinds=all .dub/build/bin/potato
==1138== Memcheck, a memory error detector
==1138== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1138== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==1138== Command: .dub/build/bin/potato
==1138==
When mashed,
==1138==
==1138== HEAP SUMMARY:
==1138== in use at exit: 24 bytes in 1 blocks
==1138== total heap usage: 88 allocs, 87 frees, 11,660 bytes allocated
==1138==
==1138== 24 bytes in 1 blocks are still reachable in loss record 1 of 1
==1138== at 0x4C2BADF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1138== by 0x4C2DE5F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1138== by 0x16BF42: _D2rt4util9container6common8xreallocFNbNiPvmZQe (in /vagrant/.dub/build/bin/potato)
==1138== by 0x17B3B9: _D2gc4impl5protoQo7ProtoGC8addRangeMFNbNiPvmxC8TypeInfoZv (in /vagrant/.dub/build/bin/potato)
==1138== by 0x172D39: gc_addRange (in /vagrant/.dub/build/bin/potato)
==1138== by 0x1844BB: _D4core6memory2GC8addRangeFNbNixPvmxC8TypeInfoZv (in /vagrant/.dub/build/bin/potato)
==1138== by 0x17DDD8: _D2rt6memory16initStaticDataGCFZ14__foreachbody1MFNbNiKSQCc19sections_elf_shared3DSOZi (in /vagrant/.dub/build/bin/potato)
==1138== by 0x16AA40: _D2rt19sections_elf_shared3DSO7opApplyFMDFKSQBqQBqQyZiZi (in /vagrant/.dub/build/bin/potato)
==1138== by 0x17DD80: _D2rt6memory16initStaticDataGCFZv (in /vagrant/.dub/build/bin/potato)
==1138== by 0x17C148: rt_init (in /vagrant/.dub/build/bin/potato)
==1138== by 0x167CCB: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv (in /vagrant/.dub/build/bin/potato)
==1138== by 0x167C63: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv (in /vagrant/.dub/build/bin/potato)
==1138==
==1138== LEAK SUMMARY:
==1138== definitely lost: 0 bytes in 0 blocks
==1138== indirectly lost: 0 bytes in 0 blocks
==1138== possibly lost: 0 bytes in 0 blocks
==1138== still reachable: 24 bytes in 1 blocks
==1138== suppressed: 0 bytes in 0 blocks
==1138==
==1138== For counts of detected and suppressed errors, rerun with: -v
==1138== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I know leaving some dangling memory towards the end of a program can be okay, but I am new to manual memory management and would feel better about my own program's memory usage if the D runtime deallocated 100% of its stuff by the end of normal program termination.
Comment #1 by n4jm4 — 2018-12-15T05:52:59Z
This happens in Debian x86_64, in VirtualBox, for what it's worth.
Comment #2 by n4jm4 — 2018-12-15T06:09:43Z
FreeBSD reports a similar mini leak, "in use at exit: 5,400 bytes in 5 blocks".
Comment #3 by robert.schadek — 2024-12-07T13:39:00Z