Re: Most common winetest failures on wine
I do not have ubuntu/mmap protection here, could you/somebody try with a
address like 0x8.
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 0x11.
The results were that on Windows XP, you get partial reads from 0x0 to 0x1,
and then full reads thereafter. On Lenny, you get full reads from 0x0 on up.
On Hardy, you get full reads from 0x1, but no partial reads at 0x0.
Therefore I now believe my patch is correct. Note that I do not
disable the probe for sub 0x1 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
#include
#include
int main(int argc, char *argv[])
{
int i;
int trymem;
int lowmem;
int highmem;
char buffer[12];
HANDLE process;
SIZE_T readcount;
int working = 0;
int partial = 0;
if (argc != 3)
{
fprintf(stderr, "%s low-mem high-mem\n", argv[0]);
exit(-1);
}
process = OpenProcess(PROCESS_VM_READ, FALSE, GetCurrentProcessId());
if (process == 0)
{
fprintf(stderr, "Error: could not open my own process for reading\n");
exit(-2);
}
sscanf(argv[1], "0x%x", &lowmem);
sscanf(argv[2], "0x%x", &highmem);
for (trymem = lowmem; trymem <= highmem; )
{
if (ReadProcessMemory(process, (void *) trymem, buffer, sizeof(buffer), &readcount))
{
if (! working)
printf("0x%x: ok\n", trymem);
working = 1;
trymem += sizeof(buffer);
}
else if (GetLastError() == ERROR_PARTIAL_COPY)
{
if (! partial)
printf("0x%x: partial\n", trymem);
partial = 1;
trymem += readcount + 1;
}
else
{
if (working)
printf("0x%x: stop\n", trymem);
if (partial)
printf("0x%x: pstop\n", trymem);
partial = 0;
working = 0;
trymem++;
}
}
return 0;
}
0x1: ok
0x0: ok
0x0: partial
0x1: ok
Re: Most common winetest failures on wine
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 . 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 0x11. I do not have ubuntu/mmap protection here, could you/somebody try with a address like 0x8. 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
Re: Most common winetest failures on wine
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.
Re: Most common winetest failures on wine
> 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 .
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 */
Most common winetest failures on wine
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 ff00". Less common is mstefani's failure, "visual.c:481: Test failed: Untransformed vertex with linear vertex fog has color 00ff". [fixme: file bugs?] urlmon:protocol has three or so failure modes; most common is "protocol.c:1597: Test failed: Read failed: 800a (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.
