4 ms·

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

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"

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"