Re: New test failures (out of the blue?)

[Reece Dunn]

2009/3/4 Paul Vriens :
> Hi,
>
> We suddenly have a new test failure on NT4 and above for advapi32:security :
>
> security.c:1202: Test failed: GetTokenInformation failed with error 998

998 = ERROR_NOACCESS -- "Invalid access to memory location."

Google (http://www.google.co.uk/search?q=ERROR_NOACCESS+GetTokenInformation&btnG...)
found http://www.cygwin.com/ml/cygwin-apps/2008-04/msg00222.html:

"For whatever reason, GetTokenInformation was failing and returning
ERROR_NOACCESS when passed a 1024 byte buffer.  I changed the code to
first call it with NULL to get the desired size, and that seems to have
satisfied it.  I cannot explain why it would object to a 1024 byte
buffer, maybe you have some idea."

That thread seems to suggest that this is an alignment issue -- the
GetTokenInformation wants the buffer to be aligned properly. Corinna
Vinschen suggests using

PTOKEN_GROUPS groups = (PTOKEN_GROUPS) alloca (size);

as alloca aligns correctly in cygwin's case.

The buffer used in the test (line 1199) is allocated on the stack as a
standard array and is thus not guaranteed to have the correct
alignment.
> And now also the rpcrt4:server test on W2K3 crashes (which it didn't before)
> although that crash is not shown on test.winehq.org (child process
> crashing?) but you will see 13 failures for this test (0 before).
>
> I haven't found the variable yet. I'm running VMware but I also see the
> advapi32 failure on a real box. My VMware image for W2K3 hasn't been updated
> since last week.

No idea for this one. Have you done a bisect?

- Reece

New test failures (out of the blue?)

[Paul Vriens]

Reece Dunn wrote:
> 2009/3/4 Paul Vriens :
> > Hi,
> >
> > We suddenly have a new test failure on NT4 and above for advapi32:security :
> >
> > security.c:1202: Test failed: GetTokenInformation failed with error 998
>
> 998 = ERROR_NOACCESS -- "Invalid access to memory location."
>
> Google (http://www.google.co.uk/search?q=ERROR_NOACCESS+GetTokenInformation&btnG...)
> found http://www.cygwin.com/ml/cygwin-apps/2008-04/msg00222.html:
>
> "For whatever reason, GetTokenInformation was failing and returning
> ERROR_NOACCESS when passed a 1024 byte buffer.  I changed the code to
> first call it with NULL to get the desired size, and that seems to have
> satisfied it.  I cannot explain why it would object to a 1024 byte
> buffer, maybe you have some idea."
>
> That thread seems to suggest that this is an alignment issue -- the
> GetTokenInformation wants the buffer to be aligned properly. Corinna
> Vinschen suggests using
> PTOKEN_GROUPS groups = (PTOKEN_GROUPS) alloca (size);
>
> as alloca aligns correctly in cygwin's case.
>
> The buffer used in the test (line 1199) is allocated on the stack as a
> standard array and is thus not guaranteed to have the correct
> alignment.

But why suddenly? I hate it when something like that happens.
> > And now also the rpcrt4:server test on W2K3 crashes (which it didn't before)
> > although that crash is not shown on test.winehq.org (child process
> > crashing?) but you will see 13 failures for this test (0 before).
> >
> > I haven't found the variable yet. I'm running VMware but I also see the
> > advapi32 failure on a real box. My VMware image for W2K3 hasn't been updated
> > since last week.
>
> No idea for this one. Have you done a bisect?

Yep, as I also had the failure when crosscompiling myself I went back to 
yesterdays build which was OK (see test.winehq.org), to no avail (it also fails).

The only thing I can think of is changes to my Fedora 10 (there were some 
updates yesterday) build. Doesn't explains the failure for that native box 
though (maybe it was the first run ever for that box, dunno).

New test failures (out of the blue?)

[Reece Dunn]

2009/3/4 Paul Vriens :
> Reece Dunn wrote:
> > 2009/3/4 Paul Vriens :
> > > We suddenly have a new test failure on NT4 and above for
> > > advapi32:security :
> > >
> > > security.c:1202: Test failed: GetTokenInformation failed with error 998
> >
> > 998 = ERROR_NOACCESS -- "Invalid access to memory location."
> > ...
> > That thread seems to suggest that this is an alignment issue -- the
> > GetTokenInformation wants the buffer to be aligned properly. Corinna
> > Vinschen suggests using
> >
> > PTOKEN_GROUPS groups = (PTOKEN_GROUPS) alloca (size);
> >
> > as alloca aligns correctly in cygwin's case.
> >
> > The buffer used in the test (line 1199) is allocated on the stack as a
> > standard array and is thus not guaranteed to have the correct
> > alignment.
>
> But why suddenly? I hate it when something like that happens.

My guess is that it was by luck or chance that was causing the buffer
to be correctly aligned on the stack. Compiler changes? Build option
changes? Wind changing direction? Who knows.
> > > And now also the rpcrt4:server test on W2K3 crashes (which it didn't
> > > before)
> > > although that crash is not shown on test.winehq.org (child process
> > > crashing?) but you will see 13 failures for this test (0 before).
> > >
> > > I haven't found the variable yet. I'm running VMware but I also see the
> > > advapi32 failure on a real box. My VMware image for W2K3 hasn't been
> > > updated
> > > since last week.
> >
> > No idea for this one. Have you done a bisect?
>
> Yep, as I also had the failure when crosscompiling myself I went back to
> yesterdays build which was OK (see test.winehq.org), to no avail (it also
> fails).
>
> The only thing I can think of is changes to my Fedora 10 (there were some
> updates yesterday) build. Doesn't explains the failure for that native box
> though (maybe it was the first run ever for that box, dunno).

Looking at those tests, Ge van Geldorp fixed a crash in those tests
that may indeed have been hiding the failures we are seeing now with
the latest tests. Also, the tests appear to be crashing (which may
have been hiding the existing failure) intermittently on different
runs, so it succeeding yesterday could be a red herring.

- Reece

New test failures (out of the blue?)

[Alexandre Julliard]

Paul Vriens  writes:
> But why suddenly? I hate it when something like that happens.

For the winehq.org builds that's most likely because the Debian updates
brought in a new MinGW.