Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Mon, 29 Dec 2003 22:04:01 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Please try the latest snapshot -- it is close to cygwin 1.5.6
Message-ID: <20031230030401.GA19492@redhat.com>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20031224152951 DOT GA34487383 AT hpn5170x> <20031223222816 DOT GA23935 AT redhat DOT com> <20031224152951 DOT GA34487383 AT hpn5170x> <3 DOT 0 DOT 5 DOT 32 DOT 20031224181524 DOT 007c21c0 AT incoming DOT verizon DOT net> <20031224232759 DOT GA12748 AT redhat DOT com> <20031226204641 DOT GA46362839 AT hpn5170x> <3 DOT 0 DOT 5 DOT 32 DOT 20031226211336 DOT 00804140 AT incoming DOT verizon DOT net> <3 DOT 0 DOT 5 DOT 32 DOT 20031226222751 DOT 00803100 AT incoming DOT verizon DOT net> <3 DOT 0 DOT 5 DOT 32 DOT 20031227182809 DOT 0082b100 AT incoming DOT verizon DOT net> <bsn3o8$lkf$1 AT sea DOT gmane DOT org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bsn3o8$lkf$1@sea.gmane.org>
User-Agent: Mutt/1.4.1i
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com

On Sun, Dec 28, 2003 at 12:26:32PM -0500, Nicholas Wourms wrote:
>Pierre A. Humblet wrote:
>>At 12:46 PM 12/27/2003 -0500, Christopher Faylor wrote:
>>
>>>I missed the 'sh -c' clue in your previous message.  Since sh uses
>>>vfork, that indicates a vfork problem.  I've checked in some more
>>>changes to deal with this.  It seems to do the right thing both with sh
>>>-c and without.  It also should have the added benefit of doing the
>>>right thing wrt deallocating the console appropriately since open_fhs
>>>should now track the ctty usecount.  This was screwed up before,
>>>apparently even before I started mucking with the tty stuff.
>>>
>>>I sure do hate usage counting.
>>>
>>>cgf
>>
>>
>>Yes, that works fine now, as does bash -c inetd.
>>
>
>Sorry to jump in on this, but I run into a few problems with the changes 
>you made last night and one issue which has been a problem for some time 
>now.
>
>This is on my Win2k box and all problems were noticed when I logged in 
>remotely via ssh (I have not tried locally).  If it makes any 
>difference, the /usr/src dir, where all my project and cygwin source is 
>contained, is a managed mount.
>
>Issues from yesterday's checkin:
>1)When run by itself from the command line, `make` is not forking 
>properly for recursive makes, instead it aborts and returns a bogus 
>HANGUP signal to the console.  This is easily seen when attempting to 
>build the Cygwin tree.  I cannot provide any useful output since it 
>appears that calling the process from within gdb or through strace 
>actually keeps make from failing to fork, but make still screws up the 
>order of entry into subdirs.

I routinely check correct cygwin operation by building cygwin so I can't
reproduce this.

>2)`procps auxf` incorrectly identifies top-parent processes as 
><defunct>, even though ps and the nt process monitor shows them to be 
>valid.  However, for postgres's postmaster, the parent and *all* 
>children are labeled as <defunct> even though I can confirm that the 
>server is up and running.

A trivial test of this, which is to run "procps auwx" from a command prompt,
does not demonstrate this here.

>3)Running configure scripts using sh.exe (which is default when you 
>./configure) always hangs, whereas running them through bash.exe works 
>fine (although it does hang from time to time).  In either case, when it 
>hangs, doing ctrl-c will drop you to the command line.  However, the 
>process isn't terminated, like one would expect.  Also, it refuses to 
>obey any signal except SIGKILL.

I don't use bash very often.  I use zsh or just the command prompt.  I
can run 'sh /whereever/configure' just fine.

>Existing issues since 1.5.5:
>3)I find myself involuntarily "logged-out" of my sessions at random 
>intervals.  This is especially prevalent when doing massive recursive 
>`rm -rf`'s or `grep -rn`'s or any other form of intensive disk i/o. 
>However, whatever is causing it seems to be getting fixed, since this 
>happens less frequently then it used to.  A small kludge I use to get 
>around this is by running links.exe then using ctrl-Z to send it to a 
>stopped state.  Then if it tries to log me out, it will fail because I 
>have a stopped process.

Again, I don't see this, so I don't know how it could be fixed.

>4)lynx crashes on startup, dropping me back to the command line. 
>Running it through gdb, the segfault happens at line 81 of cygtls.cc, 
>"_last_thread->next = this" which is inside the function 
>_threadinfo::init_thread(void*).  Unfortunately, my system is in a state 
>where I cannot get make to run correctly, so trying to build a debug 
>version of lynx at this point is not feasible.  I should note that I do 
>not see this problem inside links.

Since cygtls.c is a recent addition, this is not a 1.5.5 issue.  lynx
also works fine here.

cgf

--
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/