Most common winetest failures on wine

[Dan Kegel]

Thanks to everybody who responded to Jeremy's call
to run winetest using the 'dotests' script at
   http://wiki.winehq.org/MakeTestFailures

We now have 35 reports, and have some good data on
which test failures are common.  See the
Most Common Failures section at the bottom.
Here's what it says right now:

The skipgood script above now also tallies tests by how many people
they fail for. Currently, it shows:

35 shell32:shelllink
32 user32:msg
16 user32:input
14 ntdll:info
13 d3d9:visual
10 user32:win
8 ddraw:visual
7 urlmon:protocol
5 gdi32:font
4 winmm:wave
3 d3d9:query urlmon:url wininet:url
2 comctl32:tooltips ddraw:dsurface msxml3:domdoc quartz:referenceclock
wininet:http
1 d3d8:visual d3d9:device dinput:device dsound:ds3d dsound:ds3d8
dsound:dsound ...

Let's ignore the tests that only fail for one person for the moment,
and look at the others.

shell32:shelllink fails on all winetest reports from all machines,
including on real Windows. Yet "make test" in shell32 succeeds on this
test. Could somebody have a look at why it reliably fails under
winetest? I filed this as bug 13311.

user32:msg and user32:input are probably people running non-blessed
window managers; Alexandre's position is that we can ignore these,
since upstream gnome's WM is fixed.

ntdll:info is a flaky test marked todo_wine that succeeds sometimes:
"info.c:822: Test succeeded inside todo block: Expected to read 0
bytes, got 0"

d3d9:visual failures are all from people not running an approved
graphics card, and can be ignored (though maybe we should tell users
we only support nvidia Geforce 6 and higher for 3d graphics...)

user32:win appears to be nearly all people running unapproved window
managers, though abraml-hardy-32 did get one failure "win.c:2555: Test
failed: wrong active window (nil)" with KDE3 which should be
investigated. [fixme: file bug?]

ddraw:visual has two kinds of errors. The most common is
"visual.c:2045: Test failed: Got color 00dcdde6, expected 0000ff00".
Less common is mstefani's failure, "visual.c:481: Test failed:
Untransformed vertex with linear vertex fog has color 00ff0000".
[fixme: file bugs?]

urlmon:protocol has three or so failure modes; most common is
"protocol.c:1597: Test failed: Read failed: 8000000a (0 bytes)".
[fixme: file bug?]

gdi32:font has several failure modes, not sure what's going on there.
[fixme: file bug?]

winemm:wave might actually be a problem, perhaps Maarten can take a
look. [fixme: file bug?]

I haven't looked at the failures that happen for only 2 or 3 people.

[Jeremy White]

> ntdll:info is a flaky test marked todo_wine that succeeds sometimes:
> "info.c:822: Test succeeded inside todo block: Expected to read 0
> bytes, got 0"

Hardy seems to be the common variable for failures, and it seems as though
an actual failure reading from location 0x1234 is the trigger.
(The historically normal case, apparently, is that we succeed in
doing the read).

git-blame points at Peter as the last to touch this.
I've attached a potential patch, hopefully it'll be wrong and force
Peter to step up and fix it correctly <grin>.

Cheers,

Jeremy

diff --git a/dlls/ntdll/tests/info.c b/dlls/ntdll/tests/info.c
index 9fab806..140be05 100644
--- a/dlls/ntdll/tests/info.c
+++ b/dlls/ntdll/tests/info.c
@@ -819,7 +819,8 @@ static void test_readvirtualmemory(void)
     todo_wine{
     status = pNtReadVirtualMemory(process, (void *) 0x1234, buffer, 12, &readcount);
     ok( status == STATUS_PARTIAL_COPY, "Expected STATUS_PARTIAL_COPY, got %08x\n", status);
-    ok( readcount == 0, "Expected to read 0 bytes, got %ld\n",readcount);
+    if (status == STATUS_PARTIAL_COPY)
+        ok( readcount == 0, "Expected to read 0 bytes, got %ld\n",readcount);
     }
 
     /* 0 handle */

[Peter Oberndorfer]

On Montag 19 Mai 2008, Jeremy White wrote:
> > ntdll:info is a flaky test marked todo_wine that succeeds sometimes:
> > "info.c:822: Test succeeded inside todo block: Expected to read 0
> > bytes, got 0"
>
> Hardy seems to be the common variable for failures, and it seems as though
> an actual failure reading from location 0x1234 is the trigger.
> (The historically normal case, apparently, is that we succeed in
> doing the read).

Yes wine normally allows you to read the memory even when it should fail
(because it is reserved by the preloader? + ntdll:reserve_dos_area +
kernel32:setup_dos_mem)
-> ptrace PTRACE_PEEKDATA succeeds

But on ubuntu wine probably fails to reserve the low memory because of 
http://wiki.winehq.org/PreloaderPageZeroProblem
-> ptrace PTRACE_PEEKDATA fails to read the memory
and the read count is 0.
> git-blame points at Peter as the last to touch this.
> I've attached a potential patch, hopefully it'll be wrong and force
> Peter to step up and fix it correctly <grin>.
> The "fix" disables the readcount test for all targets running wine.
> Another workaround would be to choose another userspace address which is not 
> protected by the kernel (bigger than 65536) but still falling into the dos 
> reserve area 0x110000.
> I do not have ubuntu/mmap protection here, could you/somebody try with a 
> address like 0x80000.

Additionally the standard 0xdeadbeef address won't work here as it results in 
a different error(STATUS_ACCESS_VIOLATION for kernel space addresses instead 
of STATUS_PARTIAL_COPY ?)
> Cheers,
>
> Jeremy

Greetings Peter

[Jeremy White]

> I do not have ubuntu/mmap protection here, could you/somebody try with a 
> address like 0x80000.

I've run the attached test program on Windows XP SP3, Hardy Heron 8.04, and
a Debian 'Lenny' system for the memory range of 0x0 through 0x110000.

The results were that on Windows XP, you get partial reads from 0x0 to 0x10000,
and then full reads thereafter.  On Lenny, you get full reads from 0x0 on up.

On Hardy, you get full reads from 0x10000, but no partial reads at 0x0.

Therefore I now believe my patch is correct.  Note that I do not
disable the probe for sub 0x10000 in my patch; I simply avoid checking
readcount if the status from the read is not what we expect.

I've submitted it now to wine-patches; this fixes that particular
make test result for me.

Cheers,

Jeremy

0x10000: ok

0x0: ok

0x0: partial
0x10000: ok

[Paul Vriens]

Dan Kegel wrote:
> Thanks to everybody who responded to Jeremy's call
> to run winetest using the 'dotests' script at
>    http://wiki.winehq.org/MakeTestFailures
>
> We now have 35 reports, and have some good data on
> which test failures are common.  See the
> Most Common Failures section at the bottom.
> Here's what it says right now:
>
> The skipgood script above now also tallies tests by how many people
> they fail for. Currently, it shows:
>
> 35 shell32:shelllink
> 32 user32:msg
> 16 user32:input
> 14 ntdll:info
> 13 d3d9:visual
> 10 user32:win
> 8 ddraw:visual
> 7 urlmon:protocol
> 5 gdi32:font
> 4 winmm:wave
> 3 d3d9:query urlmon:url wininet:url
> 2 comctl32:tooltips ddraw:dsurface msxml3:domdoc quartz:referenceclock
> wininet:http
> 1 d3d8:visual d3d9:device dinput:device dsound:ds3d dsound:ds3d8
> dsound:dsound ...
>
> Let's ignore the tests that only fail for one person for the moment,
> and look at the others.
>
> shell32:shelllink fails on all winetest reports from all machines,
> including on real Windows. Yet "make test" in shell32 succeeds on this
> test. Could somebody have a look at why it reliably fails under
> winetest? I filed this as bug 13311.

I had a look at this one.

The problem as far as I can see lies with the fact that when we run 'make 
shelllink.ok' we eventually end up in UNIXFS_build_shitemid (shfldr_unixfs.c) 
where the trace shows:

trace:shell:UNIXFS_build_shitemid 
(pszUnixPath="/wine/wine-git/dlls/shell32/tests/shell32_test.exe", pIDL=0x12793a)

This shell32_test.exe doesn't exist (it's shell32_test.exe.so).

So when you do (in the test directory):

ln -s shell32_test.exe.so shell32_test.exe
rm shelllink.ok
make shelllink.ok

You will see the exact same errors as with winetest.

Winetest unpacks all it's executables in a temp directory and in this case (for 
me on the last run) it's showing in the trace:

trace:shell:UNIXFS_build_shitemid 
(pszUnixPath="/tmp/wctSkl1EH/shell32_test.exe", pIDL=0x127712)

And that file really exists.

So I guess this issue is with this piece of code in shfldr_unixfs.c:

  509     /* We are only interested in regular files and directories. */
  510     if (stat(pszUnixPath, &fileStat)) return NULL;

Now we only need a solution :-)

-- 
Cheers,

Paul.