4 ms·

> Programs built with the V compiler no longer leak memory by default. What?

by lausek 4y ago

steeleduncan 4y ago
I think it refers to the memory leak section of this https://xeiaso.net/blog/v-vaporware-2019-06-23 https://xeiaso.net/blog/v-vaporware-2019-06-23
AlbertoGP 4y ago
In addition to steeleduncan’s sibling comment, you can find more details in this bug report from 2021-03-16 that was closed as a wontfix: https://github.com/vlang/v/issues/9327 https://github.com/vlang/v/issues/9327 At the end of the thread, medvednikov wrote this just before closing the issue: > “Zero leaks when using autofree which will become the default in 0.3:” I guess they did make autofree enabled by default in this release. If they did not fix that issue it means that you still can not get leak-free programs with manual memory management, which contradicts my understanding of their claim: > “For developers willing to have more low level control, autofree can be disabled with -manualfree, or by adding a [manualfree] on each function that wants manage its memory manually.” > https://github.com/vlang/v/blob/master/doc/docs.md#control https://github.com/vlang/v/blob/master/doc/docs.md#control You can disable autofree, but then you can not have a leak-free program no matter what you do. Now, that leak is at the end of its execution so it’s not a problem when using the program, but it is when developing it as those leaks will obscure any other that you might be trying to remove, or even notice.
- amedvednikov 4y ago
  Not sure what you mean. There are no leaks by default now. If you want manual memory management, you can do that. What's the problem? And hello world hasn't been leaking for a while now, it was just an unfreed global const. The issue you referenced, wasn't closed as a wontfix. It was closed because it was fixed.
  - AlbertoGP 4y ago
    I mean what it would be nice to have no forced leaks also when using the -manualfree command line option. However, I just checked, and the 0.3 release does leak even without -manualfree! lxc launch images:debian/bullseye test-v lxc exec test-v bash # Inside the container: apt install build-essential git valgrind git clone https://github.com/vlang/v cd v git rev-parse HEAD # 74bb5ae17a4a0af8dda913ddb1ca9d8d4a590136 make # ... # Your `tcc` is working. Good - it is much faster at compiling C source code. # V has been successfully built # V 0.3.0 74bb5ae ./v examples/hello_world.v valgrind --leak-check=yes examples/hello_world # ... report about invalid read of size 1. # ... reports about uninitialized values. # ==5750== LEAK SUMMARY: # ==5750== definitely lost: 0 bytes in 0 blocks # ==5750== indirectly lost: 0 bytes in 0 blocks # ==5750== possibly lost: 1,360 bytes in 5 blocks # ==5750== still reachable: 0 bytes in 0 blocks # ==5750== suppressed: 0 bytes in 0 blocks # ... # ==5750== ERROR SUMMARY: 144 errors from 17 contexts (suppressed: 0 from 0) I checked also with the 0.3 release: https://github.com/vlang/v/releases/tag/0.3 https://github.com/vlang/v/releases/tag/0.3 apt install wget unzip rm v -r wget https://github.com/vlang/v/releases/download/0.3/v_linux.zip sha1sum v_linux.zip # bb6f81630fe2ae4e7e283360f507be99f88f32bd v_linux.zip unzip v_linux.zip cd v ./v examples/hello_world.v valgrind --leak-check=yes examples/hello_world # Exact same result as above, just a different PID of course. Am I missing something?
    - amedvednikov 4y ago
      I can't reproduce this. No leaks in valgrind for me.
    - whb07 4y ago
      ==3494== HEAP SUMMARY: ==3494== in use at exit: 0 bytes in 0 blocks ==3494== total heap usage: 6 allocs, 6 frees, 2,912 bytes allocated ==3494== ==3494== All heap blocks were freed -- no leaks are possible ==3494== ERROR SUMMARY: 260 errors from 5 contexts (suppressed: 0 from 0) I think perhaps correctly(?) The allocations are freed when running the flag "-prod" for compiling. When this flag isn't passed, you end up with: "total heap usage: 26 allocs, 11 frees, 8,702 bytes allocated"

> Programs built with the V compiler no longer leak memory by default. What?

by lausek 4y ago

> Programs built with the V compiler no longer leak memory by default. What?

I think it refers to the memory leak section of this https://xeiaso.net/blog/v-vaporware-2019-06-23 https://xeiaso.net/blog/v-vaporware-2019-06-23

AlbertoGP 4y ago

In addition to steeleduncan’s sibling comment, you can find more details in this bug report from 2021-03-16 that was closed as a wontfix: https://github.com/vlang/v/issues/9327 https://github.com/vlang/v/issues/9327 At the end of the thread, medvednikov wrote this just before closing the issue: > “Zero leaks when using autofree which will become the default in 0.3:” I guess they did make autofree enabled by default in this release. If they did not fix that issue it means that you still can not get leak-free programs with manual memory management, which contradicts my understanding of their claim: > “For developers willing to have more low level control, autofree can be disabled with -manualfree, or by adding a [manualfree] on each function that wants manage its memory manually.” > https://github.com/vlang/v/blob/master/doc/docs.md#control https://github.com/vlang/v/blob/master/doc/docs.md#control You can disable autofree, but then you can not have a leak-free program no matter what you do. Now, that leak is at the end of its execution so it’s not a problem when using the program, but it is when developing it as those leaks will obscure any other that you might be trying to remove, or even notice.

amedvednikov 4y ago
Not sure what you mean. There are no leaks by default now. If you want manual memory management, you can do that. What's the problem? And hello world hasn't been leaking for a while now, it was just an unfreed global const. The issue you referenced, wasn't closed as a wontfix. It was closed because it was fixed.
- AlbertoGP 4y ago
  I mean what it would be nice to have no forced leaks also when using the -manualfree command line option. However, I just checked, and the 0.3 release does leak even without -manualfree! lxc launch images:debian/bullseye test-v lxc exec test-v bash # Inside the container: apt install build-essential git valgrind git clone https://github.com/vlang/v cd v git rev-parse HEAD # 74bb5ae17a4a0af8dda913ddb1ca9d8d4a590136 make # ... # Your `tcc` is working. Good - it is much faster at compiling C source code. # V has been successfully built # V 0.3.0 74bb5ae ./v examples/hello_world.v valgrind --leak-check=yes examples/hello_world # ... report about invalid read of size 1. # ... reports about uninitialized values. # ==5750== LEAK SUMMARY: # ==5750== definitely lost: 0 bytes in 0 blocks # ==5750== indirectly lost: 0 bytes in 0 blocks # ==5750== possibly lost: 1,360 bytes in 5 blocks # ==5750== still reachable: 0 bytes in 0 blocks # ==5750== suppressed: 0 bytes in 0 blocks # ... # ==5750== ERROR SUMMARY: 144 errors from 17 contexts (suppressed: 0 from 0) I checked also with the 0.3 release: https://github.com/vlang/v/releases/tag/0.3 https://github.com/vlang/v/releases/tag/0.3 apt install wget unzip rm v -r wget https://github.com/vlang/v/releases/download/0.3/v_linux.zip sha1sum v_linux.zip # bb6f81630fe2ae4e7e283360f507be99f88f32bd v_linux.zip unzip v_linux.zip cd v ./v examples/hello_world.v valgrind --leak-check=yes examples/hello_world # Exact same result as above, just a different PID of course. Am I missing something?
  - amedvednikov 4y ago
    I can't reproduce this. No leaks in valgrind for me.
  - whb07 4y ago
    ==3494== HEAP SUMMARY: ==3494== in use at exit: 0 bytes in 0 blocks ==3494== total heap usage: 6 allocs, 6 frees, 2,912 bytes allocated ==3494== ==3494== All heap blocks were freed -- no leaks are possible ==3494== ERROR SUMMARY: 260 errors from 5 contexts (suppressed: 0 from 0) I think perhaps correctly(?) The allocations are freed when running the flag "-prod" for compiling. When this flag isn't passed, you end up with: "total heap usage: 26 allocs, 11 frees, 8,702 bytes allocated"