Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Mon, 5 Aug 2002 19:40:44 +0200
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: 1.3.13?
Message-ID: <20020805194044.J3921@cygbert.vinschen.de>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20020804195150 DOT GA3381 AT redhat DOT com> <124668090713 DOT 20020805140659 AT logos-m DOT ru> <20020805145655 DOT GA4698 AT redhat DOT com> <20020805154128 DOT GA5370 AT redhat DOT com> <20020805161701 DOT GA6008 AT redhat DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020805161701.GA6008@redhat.com>
User-Agent: Mutt/1.3.22.1i

On Mon, Aug 05, 2002 at 12:17:01PM -0400, Chris Faylor wrote:
> Nevermind.  I checked in a fix, I hope.  The moral of the story is that
> auto-reset events always seem to ensure a race.  I keep trying to use
> them but every time I do, a race results.

I have still a situation which fails.  I just tried a ssh localhost
which immediately died with a `connection reset by peer' message.

I tried the same with sshd started in debug mode on the command line.
ssh'ing to that sshd worked.  But when logging out again, the sshd
suddenly hangs for a while (just a few seconds) and then it crashes
which starts gdb on my box.  Unfortunately it's not visible what
exactly has happened.

The process has 10 threads, from which I can identify #1 as main thread,
#2 to #9 are threads[0-7] and #10 is unidentifiable.

#1, main, is just in start_thread_socket(), calling another `new cygthread'.
#2 == threads[0] is "sig", wait_sig()
#3 == threads[1] is "proc", wait_subproc()
#4 == threads[2] is "select_socket", thread_socket()
#5 == threads[3] has __name==NULL, thread_socket().

#6-#9 are in SuspendThread state in cygthread::stub.

#10 ???  The backtrace only contains two addresses in the system,
nothing else.  I have no idea what it does.

Of course, the effect is not reproducible under strace. :-P

I removed the "error_start=..." from $CYGWIN and created an strace
that way:

Exception: STATUS_ACCESS_VIOLATION at eip=6106F16B
eax=00000010 ebx=610CA1F0 ecx=00C9FF64 edx=00000010 esi=7FFDD000 edi=00000000
ebp=00C9FF74 esp=00C9FF5C program=C:\cygwin\usr\sbin\sshd.exe
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame     Function  Args
00C9FF74  6106F16B  (100C37D0, 00000000, 00000000, 00000001)
00C9FFB4  61004645  (610CA1F0, 00000000, 7FFDD000, 610CA1F0)
      3 [select_socket] sshd 3080 handle_exceptions: Error while dumping state (probably corrupted stack)

addr2line gives:

6106F16B = select.cc:530
61004645 = cygthread.cc:45

Do you have a spontaneous inspiration what happens?

I'm now going to return to using gdb to see if I can figure out what happens.

Corinna