This is the mail archive of the
pthreads-win32@sourceware.org
mailing list for the pthreas-win32 project.
Re: Crash when re-initializing as static library
- From: Ross Johnson <Ross dot Johnson at homemail dot com dot au>
- To: pthreads-win32 at sourceware dot org
- Date: Thu, 07 Nov 2013 10:17:28 +1100
- Subject: Re: Crash when re-initializing as static library
- Authentication-results: sourceware.org; auth=none
- References: <527A8215 dot 4010309 at tara-systems dot de>
Hi,
Applications statically linked with current versions of the library no
longer need to call those routines explicitly. From README.NONPORTABLE:
These functions contain the code normally run via DllMain
when the library is used as a dll. As of version 2.9.0 of the
library, static builds using either MSC or GCC will call
pthread_win32_process_* automatically at application startup and
exit respectively.
But you are also detaching and reattaching within the same process,
which is unintended use. Is this how you expect to use the library or
are you just analysing?
On 7/11/2013 4:53 AM, Klaus Fischer wrote:
Dear pthreads-win32 developers,
I have experienced a crash when building pthreads-win32 as static
library and re-initializing it using the following sequence:
- pthread_win32_process_attach_np()
- pthread_win32_process_detach_np()
- pthread_win32_process_attach_np()
The global variable ptw32_threadReuseTop still points to memory used
between the first attach/detach run, but this memory was already freed
in function ptw32_processTerminate(), which was called during detaching.
When using e.g. pthread_self() afterwards, the global
ptw32_threadReuseTop now points to invalid memory, causing an access
violation writing to that memory location.
A simple code change fixed that problem by assigning the default value
PTW32_THREAD_REUSE_EMPTY to that global variable at the end of
function ptw32_processTerminate(), after the while loop freeing all
still allocated thread handles.
A better way to fix that would probably be to initialize all the
library globals of global.c during the attaching stage. In a static
library, those globals are only initialized once when the process
starts, but _should_ be re-initialized on every attach.
I know this is not a concern when using this library as dynamic
library, but since there is an option to use it as static library and
other people also use it that way according to the mailing list, it
would be great if it could survive multiple re-initializations.
Thanks in advance,
Klaus