Win32 Tests

[Garrett Rooney <ro...@electricjellyfish.net>]

So I tried running testall on win32 today, and I ran into a few problems.

First off, the pipe tests seem to hang, in testpipe.c:read_write,
after setting the timeout to 1 second we never seem to come out of the
read.

Second, the socket tests seem to hang (specifically test_get_addr,
which appears to try and do a non-blocking connect, which turns out to
be anything but non-blocking).

Third, and perhaps most disturbing, the user/group tests actually
crash, apparently passing invalid gid/uids into functions like
LookupAccountSid results in a crash...  That seems kind of bad... 
According to the docs I've found on MSDN, SIDs are opaque structures
allocated by the system, not just random integers like Unix userids
and groupids, so it's not surprising that this kind of thing doesn't
work, but if that's the case you'd think we'd ifdef these tests or
something.

Finally, there are a few actual test failures (test_fail_read_flush in
testfile.c and set_timeout in testpipe.c).

Are these kind of problems par for the course on win32, or am I just
suffering from a lack of win32-fu (which is certainly possible, don't
get me wrong, I'm totally not a windows person).  If they are known
(especially the hangs and crashes, which really make the tests pretty
damn useless) that seems kind of bad to me...

Do windows APR developers just work around this sort of thing?  If so,
we should really do something about that.  We're a PORTABLE runtime,
and if we can't manage to make the tests at least run to completion on
the primary non-unix platform available, that seems like a pretty sad
state of afairs.

-garrett

Re: Win32 Tests

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Garrett Rooney wrote:
> 
> Third, and perhaps most disturbing, the user/group tests actually
> crash, apparently passing invalid gid/uids into functions like
> LookupAccountSid results in a crash...  That seems kind of bad... 
> According to the docs I've found on MSDN, SIDs are opaque structures
> allocated by the system, not just random integers like Unix userids
> and groupids, so it's not surprising that this kind of thing doesn't
> work, but if that's the case you'd think we'd ifdef these tests or
> something.

Well in -general- we avoid platform tests, because apr should do all
platform compensation for us.  In this case however, we are abusing
platform knowledge in the test to assume, for example, that user 0
might exist.  That's simply invalid.

> Do windows APR developers just work around this sort of thing?  If so,
> we should really do something about that.  We're a PORTABLE runtime,
> and if we can't manage to make the tests at least run to completion on
> the primary non-unix platform available, that seems like a pretty sad
> state of afairs.

Concurred; I've spent 95% of my time on the flaws in 0.9 (the real world,
running version) and 5% over on the 1.x side.  With the advent of 2.2 httpd,
that is rapidly flipping over.  But yes; in large part the failing tests are
invalid tests in the first place, and the few that aren't need to be addressed
in apr/win32 itself.

Bill

Re: Win32 Tests

[Garrett Rooney <ro...@electricjellyfish.net>]

On 1/21/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> So I tried running testall on win32 today, and I ran into a few problems.
>
> First off, the pipe tests seem to hang, in testpipe.c:read_write,
> after setting the timeout to 1 second we never seem to come out of the
> read.

This seems to be a bug in the tests.  Well, it's also a shortcoming in
the win32 pipe code, but the test handles it poorly, see my latest
commit to testpipe.c for the work around.

> Second, the socket tests seem to hang (specifically test_get_addr,
> which appears to try and do a non-blocking connect, which turns out to
> be anything but non-blocking).

There are a couple of things going on here.

First, we try to do a nonblocking connect from our client socket to
our server socket, but it doesn't actually work in a nonblocking
manner because the socket's timeout is still set to -1, not 0...  This
seems like a bug to me, since if you set a socket to nonblocking it
seems like it should actually not block, but I'm not sure precisely
where this should be handled.

If you hack it so that timeout gets set to 0, it still doesn't work
though, since the eventual accept doesn't complete.  I don't really
know how to debug this further, since I know very little about win32
networking stuff.  The kind of thing it's doing seems to be something
that should work (it does on unix, after all), but perhaps this is one
of those things that just won't happen on the win32 network stack.

> Third, and perhaps most disturbing, the user/group tests actually
> crash, apparently passing invalid gid/uids into functions like
> LookupAccountSid results in a crash...  That seems kind of bad...
> According to the docs I've found on MSDN, SIDs are opaque structures
> allocated by the system, not just random integers like Unix userids
> and groupids, so it's not surprising that this kind of thing doesn't
> work, but if that's the case you'd think we'd ifdef these tests or
> something.

See the patch I posted earlier today for a fix for this.

> Finally, there are a few actual test failures (test_fail_read_flush in
> testfile.c and set_timeout in testpipe.c).

Not sure what the cause of the file test failures are, haven't had
time to look at it yet, but the pipe stuff seems to be due to
shortcomings in the win32 pipe code.  In Subversion we have what is
called an XFail test for situations like this, so you can note that a
particular test is expected to fail, and later on you can be notified
if for some reason it magically starts working again.

-garrett