May 13, 2012 [D-runtime] Monitor leaks? | ||||
---|---|---|---|---|
| ||||
Hi, alexrp@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@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 _______________________________________________ D-runtime mailing list D-runtime@puremagic.com http://lists.puremagic.com/mailman/listinfo/d-runtime |
May 13, 2012 Re: [D-runtime] Monitor leaks? | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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@gmail.com> wrote: > Hi, > > alexrp@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@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 _______________________________________________ D-runtime mailing list D-runtime@puremagic.com http://lists.puremagic.com/mailman/listinfo/d-runtime |
Copyright © 1999-2021 by the D Language Foundation