|
From: | LRN |
Subject: | Re: W32 testsuite results |
Date: | Wed, 06 Apr 2011 22:17:17 +0400 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0pre) Gecko/20110405 Thunderbird/3.3a4pre |
On 06.04.2011 2:16, LRN wrote:
On 05.04.2011 23:08, LRN wrote: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)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.ccalls gnutls_transport_set_global_errno (EAGAIN); to tell gnutls librarycode 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, returnssession->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 itsvalue and sets errno.That is, the problem is in the fact that on Windows gnutls assumes thatunderlying 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 writingfor 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?FAIL: hostname-check.exe FAIL: chainverify.exe FAIL: pgps2kgnu.exe FAIL: testdsa FAIL: testselfsigsObviously, 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 thinktest-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
[Prev in Thread] | Current Thread | [Next in Thread] |