Mail Archives: cygwin/2006/07/12/06:08:10
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/
- Raw text -