Memory leak in minimal D program?

Question

This minimal program:

int main()
{
  return 0;
}

when compiled with gcc and run with valgrind works just fine.

When compiled as a D program using

dmd test_new.d && valgrind ./test_new

I get:

HEAP SUMMARY:
    in use at exit: 360 bytes in 4 blocks
  total heap usage: 22 allocs, 18 frees, 52,024 bytes allocated

LEAK SUMMARY:
   definitely lost: 288 bytes in 3 blocks
   indirectly lost: 0 bytes in 0 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 72 bytes in 1 blocks
        suppressed: 0 bytes in 0 blocks

With gdc:

gdc -o test_new test_new.d && valgrind ./test_new

I get

HEAP SUMMARY:
    in use at exit: 568 bytes in 4 blocks
  total heap usage: 23 allocs, 19 frees, 52,664 bytes allocated

LEAK SUMMARY:
   definitely lost: 496 bytes in 3 blocks
   indirectly lost: 0 bytes in 0 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 72 bytes in 1 blocks
        suppressed: 0 bytes in 0 blocks

What's wrong here?

Answer 1

My guess would be that D's runtime isn't bothering to free some of its memory, but I don't know. glibc specifically doesn't bother freeing some stuff on program shutdown on the theory that the OS is going to reclaim it as soon as the program ends anyway. D's runtime may be doing the same - though in glibc's case, they have a function that's supposed to free that stuff when you run your program with valgrind in order to not have valgrind report errors. Or D's runtime may just have an outright memory leak. It would have to be tracked down to be sure.

Answer 2

If you use the --leak-check=full option with valgrind it tells you where the leak is.

I got

    ==32630== HEAP SUMMARY:
    ==32630==     in use at exit: 136 bytes in 4 blocks
    ==32630==   total heap usage: 16 allocs, 12 frees, 49,992 bytes allocated
    ==32630== 
    ==32630== 40 bytes in 1 blocks are definitely lost in loss record 4 of 4
    ==32630==    at 0x4026A68: calloc (vg_replace_malloc.c:566)
    ==32630==    by 0x8051C93: _d_monitor_create (in /home/dave/stack/test_new)
    ==32630==    by 0x8055B4F: thread_joinAll (in /home/dave/stack/test_new)
    ==32630==    by 0x804E47E: _D2rt6dmain24mainUiPPaZi6runAllMFZv (in /home/dave/stack/test_new)
    ==32630==    by 0x804E3F3: _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv (in /home/dave/stack/test_new)
    ==32630==    by 0x804EA29: main (in /home/dave/stack/test_new)
    ==32630== 
    ==32630== LEAK SUMMARY:
    ==32630==    definitely lost: 40 bytes in 1 blocks
    ==32630==    indirectly lost: 0 bytes in 0 blocks
    ==32630==      possibly lost: 0 bytes in 0 blocks
    ==32630==    still reachable: 96 bytes in 3 blocks
    ==32630==         suppressed: 0 bytes in 0 blocks

It appears to be something to do with threading and the creation of a monitor see mutex documentation