Hey folks, I pulled down sources from CVS this morning, and tried running the regression tests. There are about 150 failures. Here's a summary:
$ grep "Test failed" log | sed 's/:.*//' | uniq -c | sort 1 filtergraph.c 1 rsaenh.c 1 shelllink.c 1 shreg.c 2 typelib.c 4 capture.c 4 wave.c 6 dsound8.c 6 dsound.c 7 vartype.c 8 path.c 15 crypt.c 43 metafile.c 51 shellpath.c
Is this unusual? How many failures are most people seeing? For what it's worth, this is a Red Hat 9.0 system with two processors, and this was done with no pre-existing .wine directory.
Also, there was a crash during the test. Here's that part of the log:
../../../../wine/tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so ../../../../wine/dlls/advapi32/tests/crypt.c && touch crypt.ok crypt.c:104: Test failed: -2146893799 crypt.c:117: Test failed: 0/-2146893799 crypt.c:126: Test failed: 0/-2146893801 crypt.c:457: Test failed: expected 234, got -2146893801 crypt.c:464: Test failed: expected 0, got 0 crypt.c:471: Test failed: expected (null), got crypt.c:472: Test failed: expected 0, got 0 crypt.c:491: Test failed: -2146893805 crypt.c:494: Test failed: -2146893805 crypt.c:502: Test failed: expected Microsoft Base Cryptographic Provider v1.0, got crypt.c:503: Test failed: expected 43, got 0 crypt.c:491: Test failed: -2146893805 crypt.c:494: Test failed: -2146893805 crypt.c:502: Test failed: expected Microsoft Base Cryptographic Provider v1.0, got crypt.c:503: Test failed: expected 43, got 0 wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x8dbe4073 in 32-bit code (0x403602e2). In 32 bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:003b GS:0033 EIP:403602e2 ESP:4073f9d2 EBP:4073fa5e EFLAGS:00010202( - 00 - -RI1) EAX:8dbe4073 EBX:404174c8 ECX:40053500 EDX:401f0b20 ESI:4073fe26 EDI:77f01330 Stack dump: 0x4073f9d2: 00004001 00000000 00000000 d14c0000 0x4073f9e2: 0c884001 13304020 fa3477f0 020f4073 0x4073f9f2: fa340000 a5864073 fa644001 009b4073 0x4073fa02: d8940000 00004002 00000001 6c644008 0x4073fa12: ffff4041 e384ffff fa2c400c 68114073 0x4073fa22: 6c644008 74c84041 fa544041 e3844073 Backtrace: =>1 0x403602e2 INSTR_EmulateInstruction+0xda(rec=0x4073fe26, context=0x4073fb5a) [../../../wine/dlls/kernel/instr.c:449] in kernel32 (0x4073fa5e) 2 0x403a441e vectored_handler+0x5e(ptrs=0x4073fa8e) [../../../wine/dlls/kernel/wowthunk.c:358] in kernel32 (0x4073fa7e) 3 0x4008bf89 call_vectored_handlers+0x5a(rec=0x4073fe26, context=0x4073fb5a) [../../../wine/dlls/ntdll/exception.c:196] in ntdll (0x4073faa2) 4 0x4008c30d EXC_RtlRaiseException+0x239(rec=0x4073fe26, context=0x4073fb5a) [../../../wine/dlls/ntdll/exception.c:252] in ntdll (0x4073fb2a) 5 0x400abe12 raise_segv_exception+0x8b(rec=0x4073fe26, context=0x4073fb5a) [../../../wine/dlls/ntdll/signal_i386.c:888] in ntdll (0x4073fb46) 0x403602e2 INSTR_EmulateInstruction+0xda [../../../wine/dlls/kernel/instr.c:449] in kernel32: movzbl 0x0(%eax),%eax Unable to open file ../../../wine/dlls/kernel/instr.c Modules: Module Address Debug info Name (17 modules) ELF 0x40000000-40016000 Deferred ld-linux.so.2 ELF 0x40017000-40030000 Deferred libwine.so.1 ELF 0x40032000-4003e000 Deferred libnss_files.so.2 ELF 0x40043000-40050000 Deferred libpthread.so.0 ELF 0x40050000-40053000 Deferred libdl.so.2 ELF 0x40054000-400d1000 Stabs ntdll<elf> -PE 0x40070000-400d1000 \ ntdll ELF 0x400d1000-401c5000 Deferred libwine_unicode.so.1 ELF 0x401c5000-401e7000 Deferred libm.so.6 ELF 0x40300000-40419000 Stabs kernel32<elf> -PE 0x40330000-40419000 \ kernel32 ELF 0x40621000-4063c000 Deferred advapi32_test<elf> -PE 0x40630000-4063c000 \ advapi32_test ELF 0x40740000-4077b000 Deferred advapi32<elf> -PE 0x40750000-4077b000 \ advapi32 ELF 0x42000000-42133000 Deferred libc.so.6 ELF 0x77f00000-77f03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\home\dank\demo\build\dlls\advapi32\tests\advapi32_test.exe 00000009 0 <== WineDbg terminated on pid 0x8
On Sun, Nov 07, 2004 at 02:19:31PM -0800, Dan Kegel wrote:
Hey folks, I pulled down sources from CVS this morning, and tried running the regression tests. There are about 150 failures. Here's a summary:
$ grep "Test failed" log | sed 's/:.*//' | uniq -c | sort 1 filtergraph.c 1 rsaenh.c 1 shelllink.c 1 shreg.c 2 typelib.c 4 capture.c 4 wave.c 6 dsound8.c 6 dsound.c 7 vartype.c 8 path.c 15 crypt.c 43 metafile.c 51 shellpath.c
Is this unusual? How many failures are most people seeing?
Hard to say, only a few. Didn't tried in recently because the tests that exercieses the xranr X server extension can randomly crash my X server (NVidia binary only) or bring it into an unusable state. But i don't blame Wine for that.
For what it's worth, this is a Red Hat 9.0 system with two processors, and this was done with no pre-existing .wine directory.
You need a .wine directory which you can create with wineprefixcreate. For a couple of tests (at least typelib) you need a native stdole32.tlb and oleaut32.dll (easiest to get by installing DCOM95 or DCOM98). The dsound tests are highly dependant on your linux sound driver.
Also, there was a crash during the test. Here's that part of the log:
bye michael
Dan Kegel wrote:
I pulled down sources from CVS this morning, and tried running the regression tests. There are about 150 failures. $ grep "Test failed" log | sed 's/:.*//' | uniq -c | sort 1 filtergraph.c 1 rsaenh.c 1 shelllink.c 1 shreg.c 2 typelib.c 4 capture.c 4 wave.c 6 dsound8.c 6 dsound.c 7 vartype.c 8 path.c 15 crypt.c 43 metafile.c 51 shellpath.c
Thanks to suggestions from Dmitry Timoshkov, Michael Jung, and Michael Stefaniuc, I'm down to only 66 or so unexplained failures now. I also discovered a bug in GetTempFileName. Details:
I rebooted into single-processor mode out of paranoia, wiped my .wine directory, and reran. Here's the new summary:
2 typelib.c 397 path.c 43 metafile.c 45 shellpath.c 4 capture.c 4 wave.c 6 dsound8.c 7 vartype.c So that fixed the dsound, filtergraph, rsaenh, shelllink, shreg, and crypt problems (guess stale registries are pretty dangerous; we do seem to need versioning...).
The typelib failures are, according to the test failure message, due to the lack of a copy of stdole32.tlb.
The metafile failures were all due to having no TrueType fonts installed. Downloading and running http://prdownloads.sourceforge.net/corefonts/courie32.exe fixed them.
The path failures are all due to t: not existing; when I create it by hand, those 397 errors go away. It sounds very much like the startup code that creates c: and z: needs to also create a t: drive!
I'll look at the rest of the failures later. I did notice a new bug, though: GetTempFileName doesn't fail if T: doesn't exist! Here's the evidence:
The first reported error in path is path.c:355: Test failed: Couldn't delete the temporary file we just created but, looking at the output of +all, I see the real first problem is not caught: 0009: create_file( access=40000000, inherit=0, sharing=00000000, create=2, options=00000050, attrs=00000080, filename="/home/dank/.wine/dosdevices/t:/pat4e0.tmp" ) 0009: create_file() = NO_SUCH_FILE { handle=(nil) } 0009:trace:heap:RtlFreeHeap (0x401f0000,00000002,40200bd8): returning TRUE 0009:Ret ntdll.NtCreateFile() retval=c000000f ret=40356581 0009:warn:file:CreateFileW Unable to create file L"T:\pat4e0.tmp" (status c000000f) 0009:Call ntdll.RtlNtStatusToDosError(c000000f) ret=403565f5 0009:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=403565f5 0009:Call ntdll.RtlFreeUnicodeString(407af548) ret=4035660d 0009:trace:heap:RtlFreeHeap (0x401f0000,00000002,40200ba0): returning TRUE 0009:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=4035660d 0009:trace:file:CreateFileW returning 0xffffffff 0009:trace:file:GetTempFileNameW returning L"T:\pat4e0.tmp"
- Dan
On Monday 8 November 2004 14:20, Dan Kegel wrote:
The path failures are all due to t: not existing; when I create it by hand, those 397 errors go away. It sounds very much like the startup code that creates c: and z: needs to also create a t: drive!
What do your $TMP and $TEMP look like?
-Hans
Hans Leidekker wrote:
On Monday 8 November 2004 14:20, Dan Kegel wrote:
The path failures are all due to t: not existing; when I create it by hand, those 397 errors go away. It sounds very much like the startup code that creates c: and z: needs to also create a t: drive!
What do your $TMP and $TEMP look like?
In the Unix shell before I start wine, they are both unset. - Dan
On Monday 8 November 2004 17:11, Dan Kegel wrote:
What do your $TMP and $TEMP look like?
In the Unix shell before I start wine, they are both unset.
I was asking because the path test uses GetTempPath which looks at $TMP and $TEMP. My $TMP and $TEMP are unset as well and I don't have a t: drive, but I can't reproduce your problem.
-Hans
On Sunday 07 November 2004 23:19, Dan Kegel wrote:
Hey folks, I pulled down sources from CVS this morning, and tried running the regression tests. There are about 150 failures. Here's a summary:
$ grep "Test failed" log | sed 's/:.*//' | uniq -c | sort 1 filtergraph.c 1 rsaenh.c 1 shelllink.c 1 shreg.c 2 typelib.c 4 capture.c 4 wave.c 6 dsound8.c 6 dsound.c 7 vartype.c 8 path.c 15 crypt.c 43 metafile.c 51 shellpath.c
Is this unusual? How many failures are most people seeing? For what it's worth, this is a Red Hat 9.0 system with two processors, and this was done with no pre-existing .wine directory.
Also, there was a crash during the test. Here's that part of the log:
Dan,
I fear that the problems with crypt.c and the crash are related to rsaenh.dll, which is pretty new in wine cvs. I can't reconstruct the test failures on my system. There are some entries in the initial registry, which did change due to rsaenh.dll. Could please retry without an existent .wine directory? (Or at least unregister rsabase and register rsaenh - regsvr32 /U rsabase ; regsvr32 rsaenh). I don't have time at the moment, but I will take a closer look tomorrow evening.
Greetings, Michael
Michael Jung wrote:
I fear that the problems with crypt.c and the crash are related to rsaenh.dll, which is pretty new in wine cvs. I can't reconstruct the test failures on my system. There are some entries in the initial registry, which did change due to rsaenh.dll. Could please retry without an existent .wine directory?
Done. (I even rebooted with nosmp.) That seems to have helped the crypt test; now I just get
../../../../wine/tools/runtest -q -P wine -M rsaenh.dll -T ../../.. -p rsaenh_test.exe.so ../../../../wine/dlls/rsaenh/tests/rsaenh.c && touch rsaenh.ok fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200f90): not verifying image fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200fb0): not verifying image fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40202598): not verifying image
which is benign, right?
Unfortunately, it uncovered some other problems, which I'll post about separately. - Dan
On Monday 08 November 2004 13:41, you wrote:
Michael Jung wrote:
I fear that the problems with crypt.c and the crash are related to rsaenh.dll, which is pretty new in wine cvs. I can't reconstruct the test failures on my system. There are some entries in the initial registry, which did change due to rsaenh.dll. Could please retry without an existent .wine directory?
Done. (I even rebooted with nosmp.) That seems to have helped the crypt test; now I just get
../../../../wine/tools/runtest -q -P wine -M rsaenh.dll -T ../../.. -p rsaenh_test.exe.so ../../../../wine/dlls/rsaenh/tests/rsaenh.c && touch rsaenh.ok fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200f90): not verifying image fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200fb0): not verifying image fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40202598): not verifying image
which is benign, right?
Yes, it is. I would even opt for removing this fixme (or changing it to a trace) and let the VerifyImage function always return TRUE. Implementing it in a sensible way would be a large effort, which would not buy us any additional functionality. This function was meant to provide two things: 1.) Enforcing US export regulations, which we should not care about (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/s...). 2.) Preventing tampering with CSP dlls, which has long been by-passed (it seems to be possible to exchange the unused NSAKEY in the binary advapi32.dll - and if you don't have write access to advapi32.dll you probably don't have write access to rsaenh.dll also).
Greetings, Michael
--- Michael Jung mjung@iss.tu-darmstadt.de wrote:
Yes, it is. I would even opt for removing this fixme (or changing it to a trace) and let the VerifyImage function always return TRUE. Implementing it in a sensible way would be a large effort, which would not buy us any
This would be really nice as I think this is what causes the .NET runtime to fail to install. When installing the free Microsoft C Compiler it bombs because it tries to install the .Net runtime and it looks like it gets all the way to the end of the install and then I see this message. I assume its doing some kind of hash check on the package and if it fails then its rolling the MSI package back.
Thanks Steven
__________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
On Monday 08 November 2004 16:47, you wrote:
--- Michael Jung mjung@iss.tu-darmstadt.de wrote:
Yes, it is. I would even opt for removing this fixme (or changing it to a trace) and let the VerifyImage function always return TRUE. Implementing it in a sensible way would be a large effort, which would not buy us any
This would be really nice as I think this is what causes the .NET runtime to fail to install. When installing the free Microsoft C Compiler it bombs because it tries to install the .Net runtime and it looks like it gets all the way to the end of the install and then I see this message. I assume its doing some kind of hash check on the package and if it fails then its rolling the MSI package back.
Sorry for being imprecise, but VerifyImage does already always return TRUE. I just meant that we should get rid of the FIXME (And that we thereby implicitly have a consensus that this feature will never be implemented, because its of no value).
On Mon, Nov 08, 2004 at 04:41:59AM -0800, Dan Kegel wrote:
Michael Jung wrote:
I fear that the problems with crypt.c and the crash are related to rsaenh.dll, which is pretty new in wine cvs. I can't reconstruct the test failures on my system. There are some entries in the initial registry, which did change due to rsaenh.dll. Could please retry without an existent .wine directory?
Done. (I even rebooted with nosmp.) That seems to have helped the crypt test;
Well, the test passes on my desktop at home (FC2 with 2.6.9 Linus kernel with SMP (HT)) but fails on my RHEL3-U3 (up2date) laptop with UP kernel.
now I just get ../../../../wine/tools/runtest -q -P wine -M rsaenh.dll -T ../../.. -p rsaenh_test.exe.so ../../../../wine/dlls/rsaenh/tests/rsaenh.c && touch rsaenh.ok fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200f90): not verifying image fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40200fb0): not verifying image fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x40202598): not verifying image
which is benign, right?
Unfortunately, it uncovered some other problems, which I'll post about separately.
On the laptop i get the typelib errors (missing DCOM9x) and capture and wave errors (sound related). Rest works like a charm (ok, i manualy create the t: drive just in case).
bye michael
-
Dan Kegel -
Hans Leidekker -
Michael Jung -
Michael Stefaniuc -
Steven Edwards