[D-runtime] Monitor leaks?

[Alex Rønne Petersen]

Also, it seems gc_init allocates an instance of the GC class with
malloc but gc_term never frees it. Anything we can do about that?

Regards,
Alex

On Sun, May 13, 2012 at 1:58 AM, Alex Rønne Petersen
<xtzgzorex at gmail.com> wrote:
> Hi,
>
> alexrp at alexrp ~/Projects/tests $ valgrind --leak-check=full ./test
> ==5100== Memcheck, a memory error detector
> ==5100== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
> ==5100== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for
> copyright info
> ==5100== Command: ./test
> ==5100==
> foo
> ==5100==
> ==5100== HEAP SUMMARY:
> ==5100==     in use at exit: 184 bytes in 4 blocks
> ==5100==   total heap usage: 20 allocs, 16 frees, 51,240 bytes allocated
> ==5100==
> ==5100== 8 bytes in 1 blocks are definitely lost in loss record 1 of 4
> ==5100==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
> ==5100==    by 0x4232E9: thread_attachThis (in /home/alexrp/Projects/tests/test)
> ==5100==    by 0x423212: thread_init (in /home/alexrp/Projects/tests/test)
> ==5100==    by 0x419D90: gc_init (in /home/alexrp/Projects/tests/test)
> ==5100==    by 0x417C99: _D2rt6dmain24mainUiPPaZi6runAllMFZv (in
> /home/alexrp/Projects/tests/test)
> ==5100==    by 0x4175FA: _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv (in
> /home/alexrp/Projects/tests/test)
> ==5100==    by 0x417592: main (in /home/alexrp/Projects/tests/test)
> ==5100==
> ==5100== 72 bytes in 1 blocks are definitely lost in loss record 4 of 4
> ==5100==    at 0x4C279F2: calloc (vg_replace_malloc.c:467)
> ==5100==    by 0x41895B: _d_monitor_create (in /home/alexrp/Projects/tests/test)
> ==5100==    by 0x416D39: _d_monitorenter (in /home/alexrp/Projects/tests/test)
> ==5100==    by 0x422EBA: _D4core6thread6Thread8isDaemonMFNdZb (in
> /home/alexrp/Projects/tests/test)
> ==5100==    by 0x419D2F:
> _D4core6thread14thread_joinAllUZv16__foreachbody299MFKC4core6thread6ThreadZi
> (in /home/alexrp/Projects/tests/test)
> ==5100==    by 0x422F4F:
> _D4core6thread6Thread7opApplyFMDFKC4core6thread6ThreadZiZi (in
> /home/alexrp/Projects/tests/test)
> ==5100==    by 0x419CA8: thread_joinAll (in /home/alexrp/Projects/tests/test)
> ==5100==    by 0x417CDF: _D2rt6dmain24mainUiPPaZi6runAllMFZv (in
> /home/alexrp/Projects/tests/test)
> ==5100==    by 0x4175FA: _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv (in
> /home/alexrp/Projects/tests/test)
> ==5100==    by 0x417592: main (in /home/alexrp/Projects/tests/test)
> ==5100==
> ==5100== LEAK SUMMARY:
> ==5100==    definitely lost: 80 bytes in 2 blocks
> ==5100==    indirectly lost: 0 bytes in 0 blocks
> ==5100==      possibly lost: 0 bytes in 0 blocks
> ==5100==    still reachable: 104 bytes in 2 blocks
> ==5100==         suppressed: 0 bytes in 0 blocks
> ==5100== Reachable blocks (those to which a pointer was found) are not shown.
> ==5100== To see them, rerun with: --leak-check=full --show-reachable=yes
> ==5100==
> ==5100== For counts of detected and suppressed errors, rerun with: -v
> ==5100== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
> alexrp at alexrp ~/Projects/tests $ cat test.d
> import std.stdio;
>
> void main()
> {
>    auto o = new Object();
>
>    synchronized (o) { writeln("foo"); }
> }
>
> Ignoring the first thread_attachThis() leak, does anyone know why
> Valgrind claims that the monitor object is being leaked?
>
> Regards,
> Alex