I have used current bench code for memory leaks hunting. This code
focuses on certain narrow functionality, so it is little bit easier to
find memory problems and locate them.
I have committed some fixes to the CVS for obviously wrong malloc vs.
gmalloc and free vs. gfree code which solved some reports from valgrind
(memcheck plugin) and some leaks in tests and code maintained by me.
For the first class of leaks, we simply can't use malloc/free for xpdf
related code. This includes also (maybe not obvious on the first glance)
string and stdlib functions which internally allocates memory like strdup (I
haven't find any others but it is good to emphasize that for record).
After I got clean reports for bench code I have checked also all kernel
tests and the result is very same.
This, of course, doesn't mean that kernel is mem-leaks-free maybe in some
error cases, which are not covered by our unit tests, we are leaking
something (especially for cases when we throw exceptions).
Finally, xpdf internal memory leaks detection code revealed to be very
helpfull. It requires DEBUG_MEM macro being defined during compilation
(we don't have any configure parameter for it at the moment - I can add
it if there is some interest for it - so you have to edit generated
Makefile.flags file and add it to the C_EXTRA and CXX_EXTRA variables).
I have added gMemReport to the test mail.cc. This function prints info
about all blocks which are not freed.
Especially usefull is the first (Index) row which stands for global
index (order) of the allocation. So if there are some printed values,
you simply need to put breakpoint to the gmalloc and set condition for
gMemIndex==PRINTED_INDEX. Then you can dump backtrace and see the place
which allocates and find out why it doesn't deallocate.
This way was little but faster especially when a code leaks only in some
conditions. Valgrind would simply show backtrace but no additional
context. However there one small glitch related with xpdf allocation
code. xpdf/goo/gmempp.cc code redefines new/delete operators to use
gmalloc/gfree functions in _global scope_.
This has side effected, that
mem leak tracking is also applied to the outside library code which
either have some leaks too, or the cleanup is done later then gMemReport
is called. This implies that we have also some spam in reports and it is
harder to focus on our leaks. Attached patch simply disables gmempp.cc
code. I don't want to push this patch to the CVS, though.
There is also negative side effect that we don't track possible mem
leaks coming from new/delete in xpdf or our code, but this can be nicely
handled via valgrind or by temporary enabling gmempp.cc code. I wasn't
able to come with nicer solution, because xpdf code doesn't use its own
namespace where we could simply define those operators and new/delete is
used way to much to change it to use some namespace.
Just to be sure that cpdf-smart_ptr patch set doesn't introduce new
mem-leaks regressions I have repeated all tests also with this patch-set
applied with the same result. I would like to do the same also for
malformed documents handling patchset.