memory leaks

[bvdberg]

I'm running the example.c in Valgrind using the static library: valgrind --leak-check=full -s ./example
Valgrind report
LEAK SUMMARY:
definitely lost: 2,248 bytes in 16 blocks
indirectly lost: 5,184 bytes in 36 blocks

I'm checking the code, but cannot easily see which free function is missing or why that would happen

[marcobambini]

Released in v0.9.8, which collects four separate leak fixes. You were right that no single missing free() explained it — the allocations were being kept alive by reference counts that never reached zero, which is why the call sites all look correct in isolation.

What was leaking

• 91ab40b — computed properties leaked by a double macro expansion in gravity_core_init (PR Fix three VM memory leaks: computed-property double creation, missing frees in gravity_core_free, orphaned GC gray-list buffer #445, thanks @barchett)
• 380aa4d — the gray-list buffer orphaned by marray_init ordering in gravity_vm_new (PR Fix three VM memory leaks: computed-property double creation, missing frees in gravity_core_free, orphaned GC gray-list buffer #445)
• 97b92c2 — Math, File, JSON and ENV never released: gravity_core_free dropped a reference without the matching balance, so the optional classes outlived every VM
• 6330961 — gravity_compiler_run took a reference to the core classes on every call and never gave it back, so the count could never reach zero and the core was never torn down

The last two are the ones that hit example.c hardest, since it does exactly one compile-and-run cycle and then tears everything down.

Measurement

I could not reproduce your valgrind figures directly — this machine is Apple Silicon and valgrind does not run there. Using the macOS leaks tool on the same examples/example.c, live allocations at process exit went from 534 blocks / 66 KB to 187 blocks / 31 KB. Both before and after, leaks reported "0 leaks", so it was classifying these as still-reachable rather than lost — the 347 blocks that are now actually released are the same objects your run reported as definitely/indirectly lost.

If you get a chance to re-run valgrind --leak-check=full -s ./example against 0.9.8, I would appreciate the numbers. If anything is still reported as definitely lost, please reopen with the output and I will take another pass.

Also in this release

While verifying the above I found a double free of the inline source buffer, fixed in 6cbf589. It only affects gravity -i, not the embedding API, so it is not related to what you saw — but it aborts under a hardened allocator, so it is worth having.

Thanks for reporting this, and for saying up front that you had looked and could not find the missing free. That was the useful signal: it pointed at refcounting rather than at a missing cleanup call.