Re: simple valgrind test found what appear to be serious memory problems

() Paul Eggert <[email protected]>
() Mon, 04 Oct 2010 15:52:17 -0700

   [tests/ overhaul ruminations]

Forget it, just thinking out loud.  Sorry for the noise.

   I tried the same simple test ("rlog INSTALL,v", with the same data
   as before) and got the following results.  Have you looked into
   those two "possibly lost" blocks?

Not yet.  FWIW, in the transition to obstacks, i did not change
the top-level pattern -- freeing the ‘SINGLE’ (file-pair) memory
*between* each pair in the main loop (see, e.g., rlog.c:922) -- so
the last pair processed will always leave something behind.  That
would explain the "still reachable", but not the "possibly lost".

   Why is the memory footprint so much greater now?

I can't provide details off-hand, but generally, using an obstack
means allocating a large amount only part of which is actually in
use.  Does valgrind have a way to count/show only the memory that
is touched?

Specifically, parsing is now complete instead of lazy.  This
allows sooner detection of file corruption, but uses more memory.

   Here are the outputs [...]

Thanks.  I see the difference in "possibly lost" between the two
outputs and will concentrate on studying that, now.