X-Spam-Check-By: sourceware.org Date: Wed, 12 Jul 2006 12:07:37 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: python test failures Message-ID: <20060712100737.GN8759@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list 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/