October 2007 - Wine-Devel - list.winehq.org

Re: ddraw:d3d tests failing consistently

by Francois Gouget

On Fri, 26 Oct 2007, Stefan Dösinger wrote: > Am Donnerstag, 25. Oktober 2007 22:15:39 schrieb Reece Dunn: > > Hi, > > > > Looking at the ddraw:d3d tests, they are failing consistently on many > > Windows platforms: > Is this a vmware system? At least two of them are (as indicated by their tags), I'm not sure about the others. Would it be possible to gather this kind of information in winetest.exe? Maybe simply grab the name of the graphics card? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner

Oct. 25, 2007

Re: ddraw:d3d tests failing consistently

by Reece Dunn

On 25/10/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Am Donnerstag, 25. Oktober 2007 22:15:39 schrieb Reece Dunn: > > Hi, > > > > Looking at the ddraw:d3d tests, they are failing consistently on many > > Windows platforms: > Is this a vmware system? This is from the http://test.winehq.org/data/200710241000/ results. 2 of the 4 failing XP boxes are labelled as being vmware, while 2 of the 3 failing 2003 machines are also labelled vmware. As for the other 3 machines, it is not clear. That said, since the same 25 tests are failing with the same got vs. expected results, it is highly likely that they are all vmware systems. - Reece

Oct. 25, 2007

Re: bug 9986

by Reece Dunn

On 25/10/2007, Juan Lang <juan.lang(a)gmail.com> wrote: > > Tests would also be useful here as well, so that there is not a regression. > > That's good general advice, but hard to implement without a serial > device to test against, which our test systems won't have. You could always skip the tests when a serial connection is not present. That way, you get coverage on systems that do have them. It should be possible to configure Virtual Machines that have serial ports suitable for use in these tests. If there are other factors that make this complicated to test (such as getting repeatable results from the serial devices on machines that have serial ports configured) then it is not worth the effort to create tests for this case. Are there any existing tests for the serial port code? If there are, that would suggest that this is possible. - Reece

Oct. 25, 2007

Re: Improving http://tests.winehq.org/data/

by Francois Gouget

On Thu, 25 Oct 2007, James Hawkins wrote: [...] > Looking at the test data, all of the msi:install tests timeout. I I believe that's because of this: * msi:automation and msi:install both time out because of this message: Service 'TestService' (TestService) could not be installed. Verify that you have sufficient privileges to install system services. Which does not make much sense since this is on Windows 9x so there's no administrator account. (In my other email I wrote that it was msi:db that timed out but now I believe it's msi:install. I'm not entirely sure though. I'll retry tomorrow evening) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

Oct. 25, 2007

Re: Improving http://tests.winehq.org/data/

by Dan Kegel

I noticed that oleaut32's typelib test failed on windows: typelib.c:65:Loading type library typelib.c:1208: Test failed: LoadTypeLibEx(wszName, REGKIND_NONE, &typelib) returned 80029c4a, expected S_OK (0) Is this because winetest.exe didn't include the files dlls/oleaut32/tests/*.tlb?

Oct. 25, 2007

Re: ddraw:d3d tests failing consistently

by Stefan Dösinger

Am Donnerstag, 25. Oktober 2007 22:15:39 schrieb Reece Dunn: > Hi, > > Looking at the ddraw:d3d tests, they are failing consistently on many > Windows platforms: Is this a vmware system?

Oct. 25, 2007

re: Improving http://tests.winehq.org/data/

by Dan Kegel

James wrote: >Looking at the test data, all of the msi:install tests timeout. I >just ran the install tests in XP running under vmware on a 3ghz >machine. The tests took 9m41s. That completely blows away the 2min >timeout. There's nothing wrong with the tests, they just take a long >time. I don't think we should extend the timeout, because it's very >subjective and more tests will be added, meaning we'll have to change >the timeout eventually. I do think we should have a flag or variable >that allows the timeout to be ignored for certain tests. Any >opinions? I'd like a way to specify the expected runtime, for use on tests that we observe take a long time. It would be used in two ways: 1) runtest could take an option --skip-long-tests which would skip all tests that had that option set, and 2) by default runtest would only abort those tests if they took one minute over their expected time (say). That would give us both a quick interactive make test and a more reliable slow-but-complete make test. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Oct. 25, 2007

Re: Improving http://tests.winehq.org/data/

by Francois Gouget

On Thu, 25 Oct 2007, Juan Lang wrote: > > - if it did not run because the tested dll did not exist at all, then > > it's not a test failure and thus the background should be green. > > A typical case would be the crypt32 tests on Windows 98. > > Actually, that's a poor case. From the Dll info section of the Windows 98 test: > crypt32=5.101.1743.1 > So why didn't the tests run at all? Ah, I missed it. An aside before I start: * it would be nice if winetest.exe had an --extract option that would just extract the individual tests so they can be run directly. It would be easier than starting winetest and fishing out the test executables from their temporary directory. * also the setupapi test is missing entirely from the website. Is it because it's missing from all the runs? If so I this means the logs should have a message for tests that cannot run. So I had a closer look at the tests that failed to run: * crypt32 does not run because of CertAddStoreToCollection(). -> commit 2002e227cfe46c08f0c765f7160fd58dba9d5c44 Author: Juan Lang <juan_lang(a)yahoo.com> Date: Fri Feb 17 17:36:52 2006 +0100 crypt32: Move certificate store functions to their own file. and -> commit 09765f7db4f8b7f4b2a57a75607c2b851e00c40d Author: Juan Lang <juan_lang(a)yahoo.com> Date: Mon Sep 25 20:24:44 2006 -0700 crypt32: Reduce indent level of tests. While I'm at it: * advapi32_test.exe does not run because of AddAccessAllowedAceEx() -> commit 3198809fd52ca3605f455c1d9b199cbf36b517c1 Author: Mikolaj Zalewski <mikolajz(a)google.com> Date: Tue Sep 25 13:12:50 2007 -0700 advapi32: Implement ConvertSecurityDescriptorToStringSecurityDescriptor[AW]. * gdi32_test.exe does not run because of GdiAlphaBlend() -> commit 9a72a865a24f4f0e43695fed48cddabd65832466 Author: Mikolaj Zalewski <mikolajz(a)google.com> Date: Tue Aug 28 10:33:29 2007 -0700 winex11.drv: Test for out-of-bound src coordinates in GdiAlphaBlend. * setupapi_test.exe does not run because of RegDeleteTreeW() What is strange is that this test is missing from the test.winehq.org page entirely. -> commit 559f89afd293547d842f7644f785521cd23f32ec Author: Juan Lang <juan.lang(a)gmail.com> Date: Fri Oct 12 08:24:27 2007 -0700 setupapi: Test SetupDiOpenDevRegKey. * shlwapi_test.exe does not run because of StrCatBuffA(). -> commit 2270cc2994ff742c937a61e2c53c06a997c1b965 Author: Miko#aj Zalewski <mikolaj(a)zalewski.pl> Date: Sun Feb 4 23:55:35 2007 +0100 shlwapi: Test string functions when buffer is too small. * wintrust_test.exe does not run because of CryptDecodeObjectEx() (from crypt32.dll) -> commit 44047e02c2f1f1497e744664611dccb67ded54b3 Author: Juan Lang <juan.lang(a)gmail.com> Date: Fri Aug 10 11:15:39 2007 -0700 wintrust: Add tests for encoding/decoding SPC links. Other total failures / timeouts: * advpack:install times out because it get stuck displaying this message: Incorrect arguments for LaunchINFSection(). Syntax: rundll32 advpack.dll,LaunchINFSection <INF Filename (required)>,<Install Section (optional)> And if I dismiss that message box I get the following message twice: Error registering the OCX C:\WINDOWS\SYSTEM\ole32.dll And finally: Error: could not locate INF file 'test.inf'. * comctl32:rebar times out using all the CPU but I don't have more info than what's already in the log. * kernel32:debugger seems to complete correctly and yet does not exit so that it times out in the end. I guess that one's for me :-/ * mshtml:htmldoc times out with not CPU usage and no additional information besides what is already in the log. * msi:automation and msi:db both time out because of this message: Service 'TestService' (TestService) could not be installed. Verify that you have sufficient privileges to install system services. Which does not make much sense since this is on Windows 9x so there's no administrator account. * ole32:marshal times out with not CPU usage and no additional information besides what is already in the log. * rpcrt4:server crashes and then times out with the message box that says: This program has performed an illegal operation and will be shut down. RPCRT4_TEST caused an exception 6c6H in module RPCRT4.DLL at 015f:7fbd90c9. Registers: EAX=000006c6 CS=015f EIP=7fbd90c9 EFLGS=00010246 EBX=0075f978 SS=0167 ESP=0075f868 EBP=0075f9b8 ECX=00000000 DS=0167 ESI=0075f970 FS=300f EDX=00530f14 ES=0167 EDI=0075f890 GS=0000 Bytes at CS:EIP: e9 4a 46 00 00 55 8b ec 83 ec 08 53 56 57 55 fc Stack dump: 7fbde7f5 000006c6 0075f890 00530540 00000019 00411414 0075f890 00431698 004223e4 00000006 0075f970 00431698 00000000 00000000 00431680 0000001a The above probably does not help much so that this will have to be taken to a debugger... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

Oct. 25, 2007

Re: crypt32: Remove a test because of a Windows 2003 SP1 bug

by Reece Dunn

On 25/10/2007, Juan Lang <juan.lang(a)gmail.com> wrote: > > I was basing it on what you said in the commit - both the heading and > > the comment in the patch. > > That's dangerous here. The details are small, but they matter: Of course the details matter. > > 1. This patch is applied to remove the test for this feature^Wbug > > in CertGetCertificateChain; > > No, the feature/bug is in CertGetIssuerCertificateFromStore. Yeah, I copied the wrong function name. My mistake. > And the > test tested for a single bit being cleared. In Windows 2003 SP1, that > bit is instead set. So leaving the test as-is is misleading: it > fails on at least one Windows platform (Windows 98 is unknown, because > the crypt32 tests aren't running there for some reason that I don't > know.) Changing it to cover both possibilities is my usual tactic, > but in the case of a single bit, there are only two possibilities. > Hence the comment in the patch: the bit being either set or cleared > is acceptable on some system on which the test is run. How, then, is > the test meaningful? Testing both cases would be silly in this instance, as you say in the comment, as it would be like testing true or false is returned from a function. The only other thing would be for either Windows to agree (which it doesn't), or there be some documentation to describe the correct behaviour, or otherwise document the bug in one of the Windows versions. Assuming that you haven't found any, there is no reference to deduce what the result should be. Therefore, I withdraw my initial objection. > > 2. Someone in the future submits a patch to fix the 'bug' in > > CertGetCertificateChain for Wine; > > No - wrong function, and one which is not inconsistent in at least > this detail on different versions of Windows. I meant to reference the other function. My mistake. > > Even if this is a deprecated API, there will still be applications > > that are dependent on it. > > Of course, and the tests for the behavior of this API that is > consistent remain. I just remove the test of this single bit, and > document why. I retract my initial comments: the patch makes sense now. - Reece

Oct. 25, 2007

Re: bug 9986

by Juan Lang

> Tests would also be useful here as well, so that there is not a regression. That's good general advice, but hard to implement without a serial device to test against, which our test systems won't have. --Juan

Oct. 25, 2007