Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Fri, 13 Jul 2001 12:49:29 -0400 From: Jason Tishler To: Greg Smith Cc: Cygwin-Developers Subject: Re: Threaded Cygwin Python Import Problem Message-ID: <20010713124929.A402@dothill.com> Mail-Followup-To: Greg Smith , Cygwin-Developers Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="E5R/EUHavDfPdc5t" Content-Disposition: inline In-Reply-To: <3B4E1CC1.813DCA2@nc.rr.com> User-Agent: Mutt/1.3.18i Organization: Dot Hill Systems Corp. --E5R/EUHavDfPdc5t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Greg, I hope that you don't mind, but I've CC'ed cygwin-developers. On Thu, Jul 12, 2001 at 05:55:13PM -0400, Greg Smith wrote: > As you may know, I have a vested interest to see the Cygwin pthreads > implementation succeed. I have had some success in debugging whatever > pthreads errors/anomalies I come across, and I am willing to spend a > little time on this problem. Thank you very much! > I am vaguely aware what Python is; if I had to give an answer right > now, I'd say it's an interpreted high-level oop type language, and > probably competes with perl with oop extensions. Correct (and a very good, concise assessment to boot). > If you can give me *explicit* instructions on how to build Python > under Cygwin and a sample script that causes the problem, I can > probably generate a stripped-down testcase in c to illustrate the > problem. Please follow the procedure describe near the end of: http://www.cygwin.com/ml/cygwin-patches/2001-q3/msg00005.html I have also attached it to this email for your convenience (and because the attachments got "smeared"). I just realized that I forgot a few cd's. The corrected instructions are: $ wget -P /tmp -nd ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/contrib/python/python-2.1-1-src.tar.gz $ # save os.py patch to /tmp $ # save test.py attachment to /tmp $ tar -xzf /tmp/python-2.1-1-src.tar.gz $ cd Python-2.1/Lib $ patch To: cygwin-patches AT cygwin DOT com Cc: Norman Vine Bcc: jt+misc DOT copy AT ny DOT dothill DOT com Subject: Re: Threaded Cygwin Python Import Problem Message-ID: <20010709171242 DOT D434 AT dothill DOT com> Mail-Followup-To: cygwin-patches AT cygwin DOT com, Norman Vine Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Ev/xH4I2Vua9nQNU" Content-Disposition: inline In-Reply-To: <20010630112019 DOT B626 AT dothill DOT com> User-Agent: Mutt/1.3.18i Organization: Dot Hill Systems Corp. --Ev/xH4I2Vua9nQNU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Rob, [Note python-dev AT python DOT org has been trimmed from the CC list.] On Sat, Jun 30, 2001 at 11:20:19AM -0400, Jason Tishler wrote: > On Sat, Jun 30, 2001 at 09:16:48AM -0400, Norman Vine wrote: > > Jason Tishler > > >The one that I would like to address in this posting prevents a threaded > > >Cygwin Python from building the standard extension modules (without some > > >kind of intervention). :,( Specifically, the build would frequently > > >hang during the Distutils part when Cygwin Python is attempting to execvp > > >a gcc process. > > I was experiencing the same problems as Jason with Win2k sp1 and > > had used the same work-around successfully. > > < I believe Jason is working with NT 4.0 sp 5 > > > > > Curiously after applying the Win2k sp2 I no longer need to do this > > and the original Python code works fine. > > > > Leading me to believe that this may be but a symptom of a another > > Windows mystery. > > After further reflection, I feel that I have found another race/deadlock > issue with the Cygwin's pthreads implementation. If I'm correct, this > would explain why you experienced it intermittently with Windows 2000 > SP1 and it is "gone" with SP2. Probably SP2 slows down your machine so > much that the problem is not triggered. :,) > > I am going to reconfigure --with-pydebug and set THREADDEBUG. Hopefully, > the hang will still be reproducible under these conditions. If so, > then I will attempt to produce a minimal C test case for Rob to use to > isolate and solve this problem. Although I have not arrived at a minimal C test case, I have attached two gdb sessions that exhibit the hang. The first one is produced by: python test.py and the second by: ./python test.py I find it curious that the hang occurs in different places dependent on how python is invoked -- via PATH or full pathname. I'm also at a lose as to why sometimes I get "Cannot access memory at address ..." errors. Can anyone explain what is going on? Note that the hang does not occur with test2.py which does not fork/exec. This seems to imply that the problem is tickled only in child processes. Is the information provided in this email useful in helping you find the problem? If not, what else can I provide to assist you? Alternatively, you can use the attached patch to build a threaded Cygwin Python to try to reproduce the problem yourself. Once built, you need to reverse the patch to exhibit the problem. The procedure is as follows: $ wget -P /tmp -nd ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/contrib/python/python-2.1-1-src.tar.gz $ # save os.py patch to /tmp $ # save test.py attachment to /tmp $ tar -xzf /tmp/python-2.1-1-src.tar.gz $ cd Python-2.1/Lib $ patch