150 test failures. advapi32 test crashes.

[Dan Kegel]

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


-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

[Michael Stefaniuc]

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
-- 
Michael Stefaniuc               Tel.: [phone]
System Administration           Fax.: [phone]
Red Hat GmbH                    Email: mstefani(a)redhat.com
Hauptstaetterstr. 58            http://www.redhat.de/
D-70178 Stuttgart

[Dan Kegel]

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

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

[Hans Leidekker]

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

[Dan Kegel]

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

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

[Hans Leidekker]

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

[Michael Jung]

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

[Dan Kegel]

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

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

[Michael Jung]

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

[Steven Edwards]

--- Michael Jung <mjung(a)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

[Michael Jung]

On Monday 08 November 2004 16:47, you wrote:
> --- Michael Jung <mjung(a)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).

[Michael Stefaniuc]

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
-- 
Michael Stefaniuc               Tel.: [phone]
System Administration           Fax.: [phone]
Red Hat GmbH                    Email: mstefani(a)redhat.com
Hauptstaetterstr. 58            http://www.redhat.de/
D-70178 Stuttgart