I am wondering if someone could interpret the valgind output for memory leak check that I see when I look for memory leaks... When a thread for creating a VM was spawned I see this output for example: ==15488== LEAK SUMMARY: ==15488== definitely lost: 9,133 bytes in 12 blocks ==15488== indirectly lost: 10,248 bytes in 5 blocks ==15488== possibly lost: 319,199 bytes in 2,887 blocks ==15488== still reachable: 4,635,633 bytes in 30,308 blocks ==15488== suppressed: 0 bytes in 0 blocks ==15488== Reachable blocks (those to which a pointer was found) are not shown. ==15488== To see them, rerun with: --leak-check=full --show-reachable=yes The traces above it show some 'wild' paths into libraries. We may either not be using the libraries correctly or they have leaks themselves ... When terminating the valgrind process by sending a -SIGTERM to it I then get this: ==15488== LEAK SUMMARY: ==15488== definitely lost: 0 bytes in 0 blocks ==15488== indirectly lost: 0 bytes in 0 blocks ==15488== possibly lost: 2,701 bytes in 25 blocks ==15488== still reachable: 543,655 bytes in 7,928 blocks ==15488== suppressed: 0 bytes in 0 blocks ==15488== Reachable blocks (those to which a pointer was found) are not shown. ==15488== To see them, rerun with: --leak-check=full --show-reachable=yes So in the end is there no leak with 'defintely and indirectly' lost being '0'? Actually other tests are not as favorable in the end: ==17333== LEAK SUMMARY: ==17333== definitely lost: 32 bytes in 1 blocks ==17333== indirectly lost: 1,449,440 bytes in 2,020 blocks ==17333== possibly lost: 1,007,275 bytes in 9,780 blocks ==17333== still reachable: 543,827 bytes in 7,933 blocks ==17333== suppressed: 0 bytes in 0 blocks ==17333== Reachable blocks (those to which a pointer was found) are not shown. ==17333== To see them, rerun with: --leak-check=full --show-reachable=yes Stefan