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

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

- Raw text -