Re: python test failures

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jul 11 22:21, Neal Norwitz wrote:
> One failure that seems to cascade into other failures is upon trying
> to lock a file.  The test is verifying that a second process can't
> open a locked file.  What I believe to be happening is that when the
> lock fails, we try to unlock the file (which we didn't lock) and that
> seems to cascade causing other failures later.  It seems that no other
> Unix system we test with has an error when trying to unlock this file,
> though I'm not sure what POSIX says should happen.  After this
> failure, it seems we can't open the file again.  I think there may be
> other problems in this test, but this seems to cause many.  Search for
> test_lock_conflict in the first link above for more details about the
> python code.  The C code (see Modules/fcntlmodule.c fcntl_lockf) looks
> like this:
> 
>                l.l_start = l.l_len = 0;
>                l.l_type = F_UNLCK;
>                ret = fcntl(fd, F_SETLKW, &l);

When and how exactly?  There are problems with file locking in that
Windows only supports mandatory file locking and the Cygwin
implementation of file locking (which is *very* old, btw) only supports
this Windows methods.  Actually one of my plans for quite some time is
to implement advisory file locking on Cygwin and drop the mandatory
locking entirely, but I never made it beyond the planning phase so far.

> The second failure seems to come about from calling msync
> (Modules/mmapmodule.c mmap_flush_method).  I believe we are just
> calling:
> 
>    msync(data, size, MS_SYNC)
> 
> and that is returning -1.

Under what circumstances?

It would be more helpful if you could provide self-contained testcases
in plain C, which can be used to reproduce the problem with a minimum
of code.  See http://cygwin.com/problems.html

> The third failure is getting a 'Connection reset by peer' on a socket
> while trying to receive 100 bytes.  The first part of the test seems
> to go ok, but after several sockets, something gets screwed up.
> 
> The last failure only occurs sometimes.  It causes python to crash
> though.  It seems to happen around forking to create new processes.
> The error message is something like:
> 
>     15 [main] python 3232 python.exe: *** fatal error - unable to
> remap lib.cygwin-1.5.19-i686-2.5\datetime.dll to same address as
> parent(0x19200000) != 0x66600000
>      8 [main] python 3100 child_copy: loaded dll data write copy
> failed, 0x187E3000..0x187E3A00, done 0, windows pid 2259364, Win32
> error 5
>  91443 [main] python 648 python.exe: *** fatal error - unable to
> remap lib.cygwin-1.5.19-i686-2.5\datetime.dll to same address as
> parent(0x19200000) != 0x66600000
>  96475 [main] python 3100 child_copy: loaded dll data write copy
> failed, 0x187E3000..0x187E3A00, done 0, windows pid 2257908, Win32
> error 5

This is the typical rebase problem.  Perl suffers from the same problem.
Did you try running rebaseall?  See /usr/share/doc/Cygwin/rebase-*.README
after installing the package.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/