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: <012001c0c0ed$fe28e910$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: =?iso-8859-1?Q?Ren=E9_M=F8ller_Fonseca?= <fonseca AT mip DOT sdu DOT dk>
Cc: <cygwin AT cygwin DOT com>
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF79B9 AT itdomain002 DOT itdomain DOT net DOT au> <3AD1A64D DOT 7DC36DF0 AT mip DOT sdu DOT dk>
Subject: Re: G++ guru's please comment - Re: FW: pthread_create problem in Cygwin  1.1.8-2]
Date: Mon, 9 Apr 2001 22:09:54 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 09 Apr 2001 12:03:26.0059 (UTC) FILETIME=[15203BB0:01C0C0ED]

----- Original Message -----
From: "René Møller Fonseca" <fonseca AT mip DOT sdu DOT dk>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: <cygwin AT cygwin DOT com>
Sent: Monday, April 09, 2001 10:08 PM
Subject: Re: G++ guru's please comment - Re: FW: pthread_create problem
in Cygwin 1.1.8-2]


> 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).

Actually I just finished pthread_once :] Talk about timing.

> 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's not a race condition per se (timing has nothing to do with it, it's
guaranteed if two or more threads enter a try block concurrently).
Something in g++ is dsiabled when it's built without thread support, and
it returns the same base address for the context struct for each thread.
That function should return a different context regardless IMO, unless
they are using pthread_key_create, which I have also implemented. There
is a patch for that in the cygwin patch list archives, and hopefully
it'll be in CVS soon. Uhmm, the delete function prototype is wrong, but
I have corrected it here. I'm putting together a new patch at the moment
which will address most of the posix prototypes, returning ENOSYS
everywhere  until I get the guts implemented. Unless there is a mass
call for a given function I'm going to send in the patch with the guts
implemented which may be a few weeks depending on time...

Of course, you could try building gcc and report back.

Rob

> 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