Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3AD1A64D.7DC36DF0@mip.sdu.dk>
Date: Mon, 09 Apr 2001 14:08:45 +0200
From: =?iso-8859-1?Q?Ren=E9=20M=F8ller?= Fonseca <fonseca AT mip DOT sdu DOT dk>
Organization: MIP, University of Southern Denmark
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
Cc: cygwin AT cygwin DOT com
Subject: Re: G++ guru's please comment - Re: FW: pthread_create problem in Cygwin 
 1.1.8-2]
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF79B9 AT itdomain002 DOT itdomain DOT net DOT au>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Please correct me if I'm wrong.

The problem, as I understand it, is that gcc is not built with thread
support which is required for exception handling to work in a
multithreaded environment. Unfortunately the thread support has not been
ported to the win32 api. I suspect functionality like "pthread_once" to
be required (tricky to implement).

The error you get is a result of a race condition on a lookup table
shared by all threads. The stack is NOT corrupted in any way.

It seems that the "lookup table" is required by the exception handling
mechanism. Alternatively it could be used for stack backtracing.

I have searched the gcc site but have only come up with the following:

See: http://gcc.gnu.org/install/configure.html

>>>
--enable-threads -- Specify that the target supports threads. This
affects the Objective-C compiler and runtime library, and exception
handling for other languages like C++ and Java. 

--enable-threads=lib -- Specify that lib is the thread support library.
This affects the Objective-C compiler and runtime library, and exception
handling for other languages like C++ and Java. 
<<<

René

Robert Collins wrote:
> 
> > -----Original Message-----
> > From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> > On Mon, Apr 09, 2001 at 11:31:57AM +1000, Robert Collins wrote:
> > >> -----Original Message-----
> >
> > I wouldn't expect the stack pointer to be screwed up.  I'd expect that
> > the *stack* is screwed up.  I don't believe that the ecx
> > register should
> > be preserved across function calls so I don't know why this
> > would mater.
> 
> Doh! Ask me how many years since I wrote assembly.... please :]
> 
> Well, the exception occurs on the last line here (Intel format cause I'm
> reading intel doco).
> 
> call   0x404c98 <sched_yield>
> mov    %eax,DWORD PTR [%ebp-100]
> add    %eax,4
> mov    %edx,DWORD PTR [%eax]
> mov    %ecx,DWORD PTR [%edx]
> mov    DWORD PTR [%eax],%ecx
> 
> As you can see, no stack references :[. And the crash doesn't occur if
> the thread doesn't lose the processor.
> 
> Now the registers should be saved when context switch's occur, so I
> don't believe the corruption occurs during that section of code, but
> rather:
> 
> first thread setsup the try{}, returning an exception handler context.
> yields.
> main runs, starts second thread
> second thread is started, it sets up it's try{}, and recieves the _sames
> context_, yields.
> first thread completes, exits the try{}, trashing the exception handler
> context.
> 
> I'm not going to look into this any alonger. IMO it's the
> __get_eh_context function in g++ which I know nothing about, and don't
> have a debug version built. I hopped on this initially to see if it was
> a pthreads issue...
> 
> If it does turn out to be cygwin threads, rather than a non-reentrant
> library function, I'm happy to look at it again.
> 
> >
> > Yep.  Probably.  Somebody should try that.
> 
> Chuckle.
> 
> > cgf
> >
> 
> Rob.
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple