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: 22 Oct 2001 20:44:50 -0400
Message-ID: <20011023004450.7072.qmail@lizard.curl.com>
From: Jonathan Kamens <jik AT curl DOT com>
To: robert DOT collins AT itdomain DOT com DOT au
CC: cygwin-developers AT cygwin DOT com
In-reply-to: <02a201c15b5b$7910a4d0$0200a8c0@lifelesswks>
	(robert DOT collins AT itdomain DOT com DOT au)
Subject: Re: 1.3.4 status?
References: <3BD4635D DOT 1060208 AT ece DOT gatech DOT edu> <20011022142729 DOT A10309 AT redhat DOT com> <20011022192430 DOT 3581 DOT qmail AT lizard DOT curl DOT com> <20011022193036 DOT 3609 DOT qmail AT lizard DOT curl DOT com> <20011022203136 DOT 5144 DOT qmail AT lizard DOT curl DOT com> <20011022203747 DOT 5162 DOT qmail AT lizard DOT curl DOT com> <02a201c15b5b$7910a4d0$0200a8c0 AT lifelesswks>

>  From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
>  Date: Tue, 23 Oct 2001 10:41:36 +1000
>  
>  So, I'd start of by hand checking the faulting line of assembly, to see
>  that is *should* work if everything where normal, and then work back
>  through the stack trace doing the same thing.

You're past my current level of knowledge -- the last time I tried to
read assembler code it was in college, and it wasn't x86 assembler
code, I can tell you that much.

All the same, right now I'm running a series of builds to see if I can
localize exactly which change checked into the repository caused the
problem to start happening.  I realize that given how random the
effects of compiler bugs and/or memory corruption can be, the change
that caused the problem to start happening may actually have nothing
to do with the problem, but it's as good a place to start as any.

Also, while I agree that there may be a compiler bug here, it seems
odd that a compiler bug would trash the stack so badly, and yet it
does look like the stack is trashed pretty badly.  In addition to the
missing calls in the stack, note also that thread 2 is completely
missing.  When I run the same program with a good DLL (i.e., one
compiled with -O2) and put a breakpoint in fhandler_console::read,
there *is* a thread 2 when the breakpoint gets hit.

Is it possible that one thread is destroying the console's tty
structure before another thread tries to use it?

  jik