Not only ~/Nim/tests/generics/trtree.nim but also the extended one with bulkloading and nearest neightbour search from https://github.com/StefanSalewski/RTree.
And fully unchanged!
Running with valgrind we get
$ nim c --gc:arc -d:useMalloc rtree.nim
$ valgrind ./rtree
==14702== HEAP SUMMARY:
==14702== in use at exit: 61,092,320 bytes in 157,909 blocks
==14702== total heap usage: 339,133 allocs, 181,224 frees, 85,099,823 bytes allocated
==14702==
==14702== LEAK SUMMARY:
==14702== definitely lost: 30,410,976 bytes in 82,268 blocks
==14702== indirectly lost: 30,681,344 bytes in 75,641 blocks
Is this something we should worry about? (There should be no cyclic references be involved.)
The memory is probably not actually "leaked", but simply not deallocated as of program exit. See, e.g.: https://stackoverflow.com/questions/31061326/why-valgrind-report-my-memory-as-definitely-lost
I'm not sure if the Nim-analogous quit(0) solution will work for the valgrind reporting. Worth a try.
Note that whatever you do to make valgrind give a nice report, you do not want to do all the time. When NOT testing for memory leaks it is much faster to let the OS reclaim memory pages/resources on process death. In an extreme case of memory swapped to Winchester drives aka spinning rust, the OS may be able to do it millions of times faster. A language run time will probably have to swap in all those evicted pages, probably even in some non-linear order seeking around.