Xapian devel - Oct 2006 - Re: [Xapian-commits] 7289: trunk/xapian-core/ trunk/xapian-core/tests/

On Fri, Oct 06, 2006 at 05:36:47PM +0100, richard wrote:
> tests/runtest.in: Cache result of test for $VG_LOG_FD if we find the new
> option.  Saves 2 seconds for each invocation on my machine, which is half
the
> time when running just a single simple test.
Nice speed up, although we might as well just remove the option and send
valgrind's output to /dev/null as things currently stand.

Sadly the whole $VG_LOG_FD scheme no longer seems to work though (I mean
before your change, I'm not saying you broke it).  I noticed a week or
two ago but haven't had time to look into it.

What it tries to do is to redirect valgrind's log output to an arbitrary
fd (255), then read from that fd inside the testsuite harness (i.e. the
program being run under valgrind) and if a test passes we just discard
any output.  If it fails because of something valgrind noticed, then we
are able to report what valgrind said.

I suspect this stopped working with changes to how valgrind works as of
valgrind 3.

If this can't be made to work now, another approach (which I think I
originally used, so hopefully is in the SVN history) is to log to a file
and note the file size before each testcase.

Unless anyone has a better idea?

Cheers,
    Olly

On Fri, Oct 06, 2006 at 06:04:26PM +0100, Olly Betts
wrote:
> Sadly the whole $VG_LOG_FD scheme no longer seems to work though (I mean
> before your change, I'm not saying you broke it).  I noticed a week or
> two ago but haven't had time to look into it.
That's a shame.

I've just committed a patch to run progsrv processes within valgrind, which
fixes bug #94, that uses this option for valgrind, even though it doesn't
work.  It may need tweaking a bit if you find a fix for the valgrind
problem.
> If this can't be made to work now, another approach (which I think I
> originally used, so hopefully is in the SVN history) is to log to a file
> and note the file size before each testcase.
> 
> Unless anyone has a better idea?
No, that sounds the best option.

-- 
Richard