Most common winetest failures on wine

[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.