[Issue 17377] New: Empty D program is not valgrind clean

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17377

          Issue ID: 17377
           Summary: Empty D program is not valgrind clean
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: druntime
          Assignee: nobody at puremagic.com
          Reporter: issues.dlang at jmdavisProg.com

When this program

import std.stdio;

void main()
{
}

is run through

valgrind --leak-check=full

it shows that we're leaking memory:

==8668== Memcheck, a memory error detector
==8668== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==8668== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==8668== Command: ./empty
==8668== 
==8668== 
==8668== HEAP SUMMARY:
==8668==     in use at exit: 88 bytes in 2 blocks
==8668==   total heap usage: 101 allocs, 99 frees, 49,704 bytes allocated
==8668== 
==8668== 16 bytes in 1 blocks are definitely lost in loss record 1 of 2
==8668==    at 0x4C2CB3F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8668==    by 0x15D0DD: _D2rt5tlsgc4initFNbNiZPv (in /home/jmdavis/empty)
==8668==    by 0x157F51: thread_attachThis (in /home/jmdavis/empty)
==8668==    by 0x157DDA: thread_init (in /home/jmdavis/empty)
==8668==    by 0x144464: gc_init (in /home/jmdavis/empty)
==8668==    by 0x13D437: rt_init (in /home/jmdavis/empty)
==8668==    by 0x13A3C9: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFNlZv
(in /home/jmdavis/empty)
==8668==    by 0x13A36B:
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFNlMDFZvZv (in
/home/jmdavis/empty)
==8668==    by 0x13A2DB: _d_run_main (in /home/jmdavis/empty)
==8668==    by 0x13A0F7: main (in /home/jmdavis/empty)
==8668== 
==8668== 72 bytes in 1 blocks are definitely lost in loss record 2 of 2
==8668==    at 0x4C2EB55: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8668==    by 0x15CFFF:
_D2rt8monitor_13ensureMonitorFNbC6ObjectZPOS2rt8monitor_7Monitor (in
/home/jmdavis/empty)
==8668==    by 0x15CF5E: _d_monitorenter (in /home/jmdavis/empty)
==8668==    by 0x157B6C: _D4core6thread6Thread8isDaemonMFNdNiNfZb (in
/home/jmdavis/empty)
==8668==    by 0x143EDE: thread_joinAll (in /home/jmdavis/empty)
==8668==    by 0x13D4E4: rt_term (in /home/jmdavis/empty)
==8668==    by 0x13A3F9: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFNlZv
(in /home/jmdavis/empty)
==8668==    by 0x13A36B:
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFNlMDFZvZv (in
/home/jmdavis/empty)
==8668==    by 0x13A2DB: _d_run_main (in /home/jmdavis/empty)
==8668==    by 0x13A0F7: main (in /home/jmdavis/empty)
==8668==
==8668== LEAK SUMMARY:
==8668==    definitely lost: 88 bytes in 2 blocks
==8668==    indirectly lost: 0 bytes in 0 blocks
==8668==      possibly lost: 0 bytes in 0 blocks
==8668==    still reachable: 0 bytes in 0 blocks
==8668==         suppressed: 0 bytes in 0 blocks
==8668==
==8668== For counts of detected and suppressed errors, rerun with: -v
==8668== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)


There's a good chance that this really doesn't matter normally, but if not even
an empty program is valgrind clean, then it's likely to be problematic to
verify that we don't have memory problems when using allocators or integrating
with C/C++.

It would not surprise me if we need a way to run druntime that indicates that
we're running valgrind so that it does cleanup that it doesn't normally do
(e.g. force the GC to clean up everything on shutdown, which it normally
wouldn't), but I don't know. Either way, valgrind indicates that we're
currently leaking with an empty main.

--