Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Date: Tue, 30 Jul 2002 08:51:39 -0400 From: Christopher Faylor To: cygwin-developers AT cygwin DOT com Cc: newlib AT sources DOT redhat DOT com Subject: Re: race in atexit.c / on_exit.c (in newlib/libc/stdlib) Message-ID: <20020730125139.GA19105@redhat.com> Reply-To: newlib AT sources DOT redhat DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com, newlib AT sources DOT redhat DOT com References: <3D46828F DOT 6090802 AT hekimian DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D46828F.6090802@hekimian.com> User-Agent: Mutt/1.3.23.1i On Tue, Jul 30, 2002 at 08:11:59AM -0400, Joe Buehler wrote: >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 >pointers. > >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... Since atexit is a newlib function, I've redirected this email to the newlib mailing list. cgf