Mail Archives: cygwin-developers/2002/07/30/08:12:03

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: <>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <>
Date: Tue, 30 Jul 2002 08:11:59 -0400
X-Sybari-Trust: 81ce3463 b923d9bf 0879ee9b 00000109
From: Joe Buehler <jbuehler AT hekimian DOT com>
Reply-To: joseph DOT buehler AT spirentcom DOT com
Organization: Spirent Communications
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cygwin Developers <cygwin-developers AT cygwin DOT com>
Subject: race in atexit.c / on_exit.c (in newlib/libc/stdlib)

I installed a patch in my local copy of Cygwin to work around null
pointer dereferences emanating from an array filled in in the newlib
atexit() / on_exit() functions.

The _fns[] array sometimes ends up with a null pointer in it, causing
a core dump, so I changed the code that dereferences the array
elements (calls the function pointers in the array) to ignore null

Looking at the instructions generated by gcc, it looks like this is
probably another race condition in cygwin.  If two threads execute
atexit()/on_exit() at the same time, they can overwrite the same entry
in the _fns[] array, then double-increment the array index, thus
(probably) leaving a null pointer in the array.

If this is indeed what is happening, my fix avoids the core dump, but
at the cost of not executing an atexit() function that might be rather
important Cygwin cleanup code.  So I'm going to try some C code
variations that might make the code thread-safe...

Joe Buehler

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019