This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: G++ guru's please comment - Re: FW: pthread_create problem in Cygwin 1.1.8-2]
----- Original Message -----
From: "René Møller Fonseca" <fonseca@mip.sdu.dk>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <cygwin@cygwin.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@redhat.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