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
Date: Mon, 9 Apr 2001 10:47:06 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: G++ guru's please comment - Re: FW: pthread_create problem in Cygwin 1.1.8-2]
Message-ID: <20010409104706.A29382@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF79B9 AT itdomain002 DOT itdomain DOT net DOT au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <EA18B9FA0FE4194AA2B4CDB91F73C0EF79B9@itdomain002.itdomain.net.au>; from robert.collins@itdomain.com.au on Mon, Apr 09, 2001 at 02:34:04PM +1000

On Mon, Apr 09, 2001 at 02:34:04PM +1000, 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.

I'm confused by this snippet of assembly.  It looks like gcc is using
the result of sched_yield to index into a table.  But, %eax should be
either 0 or 1 in this case.  So, maybe you're right.  This is a gcc
problem.  And, it may be fixed by configuring gcc with --enable-threads.

This is one of those situations where it looks like gcc can't be
released until a version of cygwin is released with the requisite
functionality.

cgf
>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

-- 
cgf AT cygnus DOT com                        Red Hat, Inc.
http://sources.redhat.com/            http://www.redhat.com/

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