This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: race in atexit.c / on_exit.c (in newlib/libc/stdlib)
- From: Christopher Faylor <cgf at redhat dot com>
- To: cygwin-developers at cygwin dot com
- Cc: newlib at sources dot redhat dot com
- Date: Tue, 30 Jul 2002 08:51:39 -0400
- Subject: Re: race in atexit.c / on_exit.c (in newlib/libc/stdlib)
- References: <3D46828F.6090802@hekimian.com>
- Reply-to: newlib at sources dot redhat dot com
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