Mail Archives: cygwin/2001/04/09/08:22:41
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
- Raw text -