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 Message-ID: <3D46828F.6090802@hekimian.com> Date: Tue, 30 Jul 2002 08:11:59 -0400 X-Sybari-Trust: 81ce3463 b923d9bf 0879ee9b 00000109 From: Joe Buehler 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 Subject: race in atexit.c / on_exit.c (in newlib/libc/stdlib) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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... Joe Buehler