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
Message-ID: <3E4D06B8.5010306@hekimian.com>
Date: Fri, 14 Feb 2003 10:09:44 -0500
X-Sybari-Trust: b66e2920 f29b823d 2b08c392 00000139
From: Joe Buehler <jbuehler AT hekimian DOT com>
Reply-To: jbuehler AT hekimian DOT com
Organization: Spirent Communications, Inc.
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021212
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cygwin Developers <cygwin-developers AT cygwin DOT com>
Subject: gcc static constructor multi-threading flaw
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Christopher (Faylor):

Would you accept patches to gcc / cygwin to add locking to
function-private static object constuction?

Gcc generates calls to atexit() when entering a function
that has a private static object.  It does this to schedule
a call to the destructor at program exit time.

The atexit() function is not thread-safe, however.  I posted
an explanation to the newlib list, but looking at the newlib
code, it appears that newlib is not really set up for locking,
so a fix is probably not going to be forthcoming from there.

One possible fix is to have gcc call a wrapper function
that performs locking and then calls atexit().  I suppose
another way to do it without touching gcc is #define
manipulation to replace atexit() with a Cygwin wrapper.

The reason for all this is that I sometimes get crashes in
cygwin processes at program exit time because of corruption
of atexit() internal data.  Any multi-threaded Cygwin app is
going to risk this problem.  There are currently 4 such
objects in cygwin1.dll itself.  No idea how many there are
when you count all the apps.

Note that this is not a total fix.  As I recall, the code
generated by gcc is inherently not thread-safe -- it's testing
a global to see whether to do the constructor/destructor code
block, and there is a race condition.
-- 
Joe Buehler