[Xapian-devel] Re: [Xapian-commits]7990: trunk/xapian-core/trunk/xapian-core/bin/trunk/xapian-core/tests/harness/

[Mark Hammond]

Olly writes:
>
> On Sun, Apr 01, 2007 at 03:50:53PM +0100, Olly Betts wrote:
> > On Mon, Apr 02, 2007 at 12:05:44AM +1000, Mark Hammond wrote:
> > > It's all working fine for me - thanks!  I've a few
> outstanding patches from
> > > xapian-maintainer-tools/win32msvc, but I'll add them to
> bugzilla over the
> > > next few days.
> >
> > Interesting - does "make check" currently pass for you under MSVC?
>
> Still interested to know this!

there appears to be no target named 'check' in the top-level MSVC makefile.
However, that makefile does appear to automatically run all tests.  So after
a top-level build, I always have apitest.exe executed, generating the number
of failures I summarised before.  The make process then terminates due to
apitest.exe failing.  I've not checked if other tests are expected to be run
after apitest.

Output is:

...
apitest total: 448 tests passed, 126 failed, 11 skipped.
NMAKE : fatal error U1077: 'apitest' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio .NET
2003\VC7\BIN\nmake.exe"' : return code '0x2'
Stop.

> It doesn't appear to be timing issues.  It seems to be
> particular tests
> which fail to connect.  The error isn't much help:
>
> C:\xapian-core\tests>apitest -v -b remotetcp emptyquery1
> Running anydb tests with remotetcp backend...
> Running test: emptyquery1...The process cannot access the
> file because it is bei
> ng used by another process.
>  EXCEPTION: Program failed with exit code 1: start
...

Yeah, I assumed it was due to 2 processes attempting to redirect to the same
file.  For example, if I execute:

% python > \temp\delme.out

And then attempt to do the same thing again while the first is running, I
get:

% python > \temp\delme.out
The process cannot access the file because it is being used by another
process.

Which is the same error message shown above.  I assumed the message was the
result of another instance terminating (but still executing, so still having
the file open), while the next test instance was being started.

> So in conclusion, I think we need to stop using SO_REUSEADDR
> on Windows.  And
> perhaps we should also use SO_EXCLUSIVEADDRUSE where
> available but there seem
> to be drawbacks so I'd like input from someone who actually
> knows more about
> the murky world of winsock...

I'm afraid that isn't me :(  I believe your analysis is correct though, and
that not attempting address reuse makes sense in this context (and indeed
*all* contexts on Windows :)

Mark