Runtime reporting some leftover bytes at termination

[mcandre]

Hey, I'm using valgrind to scan my CloudABI programs for any memory leaks. The good news is, my short example programs appear to be clearing their heap fairly well. The bad news is, our runtime appears to leave a few bytes hanging when exit() runs.

Now, this is not exactly critical, but it does muddy the water when programmers are trying to make sense of the valgrind output.

Source

https://github.com/mcandre/tonixxx/tree/issue-115/examples/fewer

Trace

$ valgrind --error-exitcode=1 --leak-check=full cloudabi-run -e bin/fewer <cloudabi-unittest.yml
==1305== Memcheck, a memory error detector
==1305== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1305== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1305== Command: cloudabi-run -e bin/fewer
==1305== 
WARNING: Attempting to start executable using emulation.
Keep in mind that this emulation provides no actual sandboxing.
Though this is likely no problem for development and testing
purposes, using this emulator in production is strongly
discouraged.
==1305== 
==1305== HEAP SUMMARY:
==1305==     in use at exit: 23,703 bytes in 158 blocks
==1305==   total heap usage: 6,754 allocs, 6,596 frees, 181,227 bytes allocated
==1305== 
==1305== LEAK SUMMARY:
==1305==    definitely lost: 0 bytes in 0 blocks
==1305==    indirectly lost: 0 bytes in 0 blocks
==1305==      possibly lost: 0 bytes in 0 blocks
==1305==    still reachable: 23,703 bytes in 158 blocks
==1305==         suppressed: 0 bytes in 0 blocks
==1305== Reachable blocks (those to which a pointer was found) are not shown.
==1305== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1305== 
==1305== For counts of detected and suppressed errors, rerun with: -v
==1305== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Could we clear up these hanging blocks, so that programmers see only their particular application's leaks?

[EdSchouten]

I'm not sure there's a lot we can do here. You're running valgrind against cloudabi-run -e. I don't think a tool like valgrind could accurately trace memory allocations performed by the CloudABI process running inside of the emulator.

You are likely seeing memory leaks in the emulator itself. If those leaks are harmful, we should of course fix them. Ones that are benign may not be trivial to fix, due to the way control flow is done within the emulator.