Hi,
In an effort to get everything green I'm trying to fix some long standing setupapi test failures.
In one of the tests, test_SetupDecompressOrCopyFile() in misc.c, we call SetupDecompressOrCopyFileA a few times. One of them fails as the target file is still open and doesn't allow reading from it (ERROR_SHARING_VIOLATION).
This only happens when running winetest and not when running the single tests. Once all tests are finished that previously 'locked' file can be removed.
I'm building my own winetest where I selectively removed some of the tests.
If I remove for example comctl32/d3d9/fusion/kernel32/riched20 the setupapi tests succeed. Other combinations are however also possible to make the tests pass (for example everything up to d3d8).
I do see that on Win98 several processes are started due to some tests needing functionality (like 'rpcss.exe', 'spool32.exe', 'pstores.exe', 'ddhelp.exe'). These processes however have only handles to the winetest results file and not to the mentioned setupapi test file.
I'm a bit lost where I should be looking so any ideas, suggestions would be appreciated. I don't know when these tests started failing but I found some failures in test results as far back as May 30th 2008 (WinMe).
It's also worth mentioning that not all Win9x/WinMe boxes fail and that the failures happen on both VMware and real boxes.
Could it be that we are not cleaning up properly after some tests? Most things should however be cleaned up when we exit a test (like freeing libraries, closing open handles etc...), not?
On Tuesday 20 October 2009 10:07:07 am Paul Vriens wrote:
In an effort to get everything green I'm trying to fix some long standing setupapi test failures.
In one of the tests, test_SetupDecompressOrCopyFile() in misc.c, we call SetupDecompressOrCopyFileA a few times. One of them fails as the target file is still open and doesn't allow reading from it (ERROR_SHARING_VIOLATION).
Looking at http://test.winehq.org/data/9390bc921e012888d488e8314a4379bc76e2c4d4/98_gvg-...
the problem seem to center around LZ compression. ERROR_READ_FAULT is returned before the sharing violation so it looks like 9x did not clean up properly there.
I would suggest to skip the LZ related tests on 9x.
-Hans
On 10/20/2009 10:37 AM, Hans Leidekker wrote:
On Tuesday 20 October 2009 10:07:07 am Paul Vriens wrote:
In an effort to get everything green I'm trying to fix some long standing setupapi test failures.
In one of the tests, test_SetupDecompressOrCopyFile() in misc.c, we call SetupDecompressOrCopyFileA a few times. One of them fails as the target file is still open and doesn't allow reading from it (ERROR_SHARING_VIOLATION).
Looking at http://test.winehq.org/data/9390bc921e012888d488e8314a4379bc76e2c4d4/98_gvg-...
the problem seem to center around LZ compression. ERROR_READ_FAULT is
I traced the compare_file_data() function and the target file couldn't be opened (sharing error) and that's why the tests on line 554 failed. Don't know why SetupDecompressOrCopyFileA returns ERROR_READ_FAULT though in that next call.
returned before the sharing violation so it looks like 9x did not clean up properly there.
You mean just in the setupapi tests before that error? It doesn't explain however why it only fails in some circumstances.
I would suggest to skip the LZ related tests on 9x.
That's the easy way out ;). I do want to try to get to the bottom of this. We have many tests out there that fail intermittently, probably because of us not cleaning up properly or when running the tests a second time on a non-clean system.
-
Hans Leidekker -
Paul Vriens