Bug 19490 – valgrind: in use at exit: 24 bytes in 1 blocks

Status
NEW
Severity
enhancement
Priority
P4
Component
druntime
Product
D
Version
D2
Platform
x86
OS
Mac OS X
Creation time
2018-12-15T05:52:25Z
Last change time
2024-12-07T13:39:00Z
Assigned to
No Owner
Creator
n4jm4
Moved to GitHub: dmd#17377 →

Comments

Comment #0 by n4jm4 — 2018-12-15T05:52:25Z
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
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17377 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB