Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Fri, 19 Jul 2002 22:30:06 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: [bug found] Re: cygwin hang problem
Message-ID: <20020720023006.GB4688@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <3D32FC00 DOT 5090108 AT hekimian DOT com> <20020719050925 DOT GA24259 AT redhat DOT com> <3D37F0E5 DOT 50F3669B AT yahoo DOT com> <20020719141242 DOT GB27697 AT redhat DOT com> <3D38949C DOT 3090200 AT hekimian DOT com> <3D38C63B DOT 1070201 AT hekimian DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D38C63B.1070201@hekimian.com>
User-Agent: Mutt/1.3.23.1i

On Fri, Jul 19, 2002 at 10:08:59PM -0400, Joe Buehler wrote:
>OK, I think I see what the problem may be.  In the dll_func_load
>code (assembly language), the dll linkage code is patched (rewritten)
>once the address of the loaded dll function is known.  The problem
>is that there is a race -- the new opcode and its argument
>are written separately.  What happens is this:
>
>1. a mov instruction is overwritten with 0xe9 to become a jmp
>2. another thread executes the jmp before step 3
>3. the newly written jmp instruction gets the proper offset written
>
>Since the mov instruction uses an offset from the beginning of the segment,
>and the jmp uses an EIP-relative offset, the net effect is that the jmp
>goes off in the weeds.  The data in the dll linkage code is what causes
>the observed behavior of a jump to twice the value of the linkage data --
>the mov instruction references memory just a few bytes further down.
>
>In the core that I am looking at, here is what is at win32_CopySid AT 12:
>
>0x610f00b8: 0xa1 0xbf 0x00 0x0f 0x61 # mov 0x610f00bf,%eax
>
>This becomes -- at just the wrong moment:
>
>0x610f00b8: 0xe9 0xbf 0x00 0x0f 0x61 # jmp %eip+0x610f00bf
>
>So the locking needs some changing in the dll linkage code.  There is
>in fact a comment above dll_func_load that the code may not be thread
>safe!

Right.

What two threads are accessing this info simultaneously?  It's probably
easier to fix that than to introduce locking.

cgf