Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Sat, 5 May 2001 12:47:37 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygdev <cygwin-developers AT cygwin DOT com>
Subject: Re: Fix for ssh problems
Message-ID: <20010505124737.B4038@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygdev <cygwin-developers AT cygwin DOT com>
References: <20010504224503 DOT A20310 AT redhat DOT com> <20010505104012 DOT A29822 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <20010505104012.A29822@cygbert.vinschen.de>; from vinschen@redhat.com on Sat, May 05, 2001 at 10:40:12AM +0200

On Sat, May 05, 2001 at 10:40:12AM +0200, Corinna Vinschen wrote:
>On Fri, May 04, 2001 at 10:45:03PM -0400, Christopher Faylor wrote:
>> Corinna reported a problem with sshd and debugged it enough that I
>> could (eventually) figure out what I think was happening.  I just
>> checked in a fix for the problem, I hope.
>> 
>> I don't know if this will fix Matt's ssh problems or not, but please
>> give the current CVS Cygwin a try.
>
>It fixes my sshd problem AFAICS. I have used ssh and scp a lot now
>and it didn't hang so far.
>
>Thank you,

You're welcome.  Interesting how my fixes which "couldn't possibly
affect anything else" ended up affecting everything else.

It only took two days or so for me to realize that my stack walking code
was screwed up.  The way signals work is that cygwin routines register
their frame pointers on entry.  If a signal occurs, then the location on
the stack which has the return address is replaced with a call to a
signal handler prefix which resets a "signal_arrived" event and calls
any appropriate signal handler.

I'd changed things so that the call to the signal handler prefix was
being put on the caller of the function's return rather than the
functions return.  So, the signal_arrived event was never being reset.
This caused a WaitForMultipleObjects in select() to be continually
triggered.

I have had this problem so many times that I'm embarrassed that it took
two days for me to figure out what the problem was.  This was due to my
changes to the stack dump stuff in cygwin.  It uses the same code to
walk the stack as the signal handler.  So, when I made the stack dumper
work better for exceptions, I broke the signal handler.

Exceptions are strange because, while they set up something that looks
like a frame pointer on the stack, it isn't a true frame pointer, so you
have to make allowances.  You don't have to make those allowances for
the signal handler.

After seeing this problem, I have another idea on how to handle signals.
It could be a cleaner implementation but now that the current version
isn't broke, I'm a little reluctant to fix it.  Maybe in 1.3.4...

cgf