Re: W32 testsuite results

[LRN]

On 06.04.2011 2:16, LRN wrote:
> On 05.04.2011 23:08, LRN wrote:
> > On 05.04.2011 22:59, Nikos Mavrogiannopoulos wrote:
> > > On 04/05/2011 02:27 PM, LRN wrote:
> > >
> > > > > This shouldn't be a problem. The mini-* programs use fd==0xfffffff
> > > > > because they emulate the communication and don't really use an fd.
> > > > I think i've found the problem. The code in client_pull() in mini.c
> > > > calls gnutls_transport_set_global_errno (EAGAIN); to tell gnutls 
> > > > library
> > > > code that the pull operation should be postponed. However, gnutls
> > > > library code in _gnutls_read() in gnutls_buffers.c:306 calls int err =
> > > > get_errno (session); to obain errno, which, in turn, returns
> > > > session->internals.errno_func 
> > > > (session->internals.transport_recv_ptr);,
> > > > which is the same as 
> > > > system_errno(session->internals.transport_recv_ptr)
> > > > at system.c:55, which simply calls WSAGetLastError(), switch'es 
> > > > over its
> > > > value and sets errno.
> > > > That is, the problem is in the fact that on Windows gnutls assumes 
> > > > that
> > > > underlying read() implementation is incapable of setting errno and is,
> > > > in fact, a socket (since gnutls uses WSAGetLastError()).
> > > > Possible fixes:
> > > > A) Fix gnutls_transport_set_global_errno() to call SetLastError() 
> > > > (note
> > > > that there's no difference between WSAGLE and GLE, unless you're 
> > > > writing
> > > > for WinSock 1.x, which is crazy, because WinSock 2.x has been shipped
> > > > with NT since NT 4.0). And maybe set errno too, just to be safe.
> > > I think I'll switch it to gnutls_transport_set_errno(), fix and
> > > deprecate the set_global_errno() function. I don't see any point
> > > in it as a function.
> > How do you access a session object in pull function?
> Anyway, i've fixed it in my local copy (patch is attached; since i 
> don't know how to access session in pull(), my patch is a bit crude)
>
> FAIL: hostname-check.exe
> FAIL: chainverify.exe
> FAIL: pgps2kgnu.exe
> FAIL: testdsa
> FAIL: testselfsigs
>
> Obviously, the improvement is considerable. Half of safe-renegotiation 
> tests failed previously, now they all pass. Mini and its variants all 
> pass.
>
> hostname check might fail because 
> function_to_get_host_by_ip(127.0.0.1) != "localhost" (known winsock bug).
>
> chainverify fails because 2 certificates have expired in January 2011. 
> A patch fixes that (although it would be better to get some new 
> certificates for this test, no?)
>
> pgps2kgnu fails because of unexplainable (and quiet!) strstr() failure 
> in armor_decode:
>
> I have no explanation whatsoever. Gnulib does not override this 
> function, it is imported from msvcrt.
> mbsstr works correctly (at least when called from gdb). Also, gnulib 
> warns about strstr() not working with multibyte charsets. This is not 
> the case here, but makes me wonder. I'll dig further.
The newest batch of patches (no pun intended) is attached.
Fixes:

hostname-check - as a side-effect of fixing pgps2kgnu, i think

test-binary-io - as i have thought, it's a libtool wrapper bug: instead 
of exec()'ing it spawnv()'s its child, and because of that it keeps 
sitting on top of stdout FD, blocking it, which prevents its child from 
stat()'ing it later to get its size. Hacking the script to run 
.libs/test-binary-io.exe instead solves the problem

pgps2kgnu - armor.c had a weird notion that on Windows all text files 
have CRLF EOLs, while on other systems all files have LF EOLs, no 
exceptions. Obviously this is not the case in objective reality (you can 
get certificates from wide variety of sources, some of them originate 
from different OSes), particularly in this testcase (in which the 
certificate has only LF EOLs). I've modified the code to try to match an 
empty line to both \n and \r\n. Also modified it to strip (when 
stripping EOLs) \n first, and then strip \r if it is present.
It should be noted that gdb lied about the string contents. I've been 
able to find the source of the problem only by inserting debug logging 
statements all over the place. Never trust gdb! :)

testselfsigs - Probably I/O-related. Running certtool with --infile 
"filename" appears to be working, while running with <"filename" fails 
(certtool.exe: import error: The scanning of a large integer has 
failed). I've fixed the test script to use --infile (much easier than 
hacking the source yet again to be able to debug it with gdb while 
feeding data from stdin; might be related to the way msys does its piping).

Now the only problem left is:
FAIL: testdsa
still hangs. Not sure why, too complex for me to debug. Logs are attached.

patches.tar.xz
Description: Binary data

testdsa.logs.tar.xz
Description: Binary data