On Sun, Mar 09, 2025 at 11:46:41AM +0100, Patrice Dumas wrote: > > For tests, I assume it could be checked if TEST is set? > > Yes. > > > Can the tests > > be used for checking if all memory is freed by the end? > > Not directly, the way I observe it is by looking at valgrind > reachable/total memory. But freeing explicitly the tree in tests makes > sure that a double free is caught, and also that if part of the tree is > free'd and not another it appears as a memory leak in valgrind. > > > Also, maybe more 'philosophically', not freeing this memory is a bit > like accepting that memory leaks are not an issue if the speed gain is > important when the memory is only released at exit.
I don't accept the term "memory leak" to refer to still allocated memory at the end of the program. In the past, I found that valgrind would not report a leak if the program ended with "exit (0)" at the end of 'main' rather than "return", as local variables in 'main' would still reference the memory. Memory referenced by global (or static) variables would also not be viewed as lost. More recently I found this could be affected by optimization settings. That is the reason for my comment in README-hacking regarding the info tests: "Note that a small number of tests may report leaks unless info is compiled with CFLAGS='-O0'." There's no point in doing expensive clean-up operations immediately before exiting the program. The only point would be if valgrind could not cope with it and real memory leaks were being obscured. > Indeed, the > unrealeased memory is a memory leak from the whole Perl+C program point > of view, as the Perl object that could be used to retrieve the C to be > freed is lost (it is not fully lost, all the documents may still be > released, but the handler to this specific document is lost). (As a > side note, the document holds Perl references, such that if it is not > free'd, Perl will not be able to collect this memory. Since we are at > the end of the program, not allowing Pelr to release memory it probably > also speeds up the program). As far as I know Perl does not clean up all of its allocations unless the "destruct level" is set with e.g. Perl::Destruct::Level. > If I read well, this is significant, but not a big relative difference. About 1.5% I believe.
