Re: Crash when re-initializing as static library

[Ross Johnson <Ross.Johnson@homemail.com.au>]

Hi Klaus,

Thanks for providing the extra context. I'll apply your suggested 
change/s, probably early next week.

Regards.
Ross

On 8/11/2013 1:19 AM, Klaus Fischer wrote:
> Let me give you a little background in order to understand my situation:
>
> I'm actually using the Portable SDK for UPnP Devices (libupnp), which 
> in turn relies on pthreads. I'm developing cross-plattform 
> (Windows/Linux), so I need Pthread-Win32 (henceforth called PTW32) to 
> enable libupnp to run under Windows.
>
> libupnp in turn initializes and deinitializes PTW32 every time libupnp 
> itself gets initialized/deinitialized. De-/initialization of PTW32 is 
> explicitly done via pthread_win32_process_* when libupnp is compiled 
> for WIN32 and PTW32 is used as a static library. This is still done 
> that way in the latest libupnp release (1.6.18).
>
> One of my first tests was to repeatedly call UpnpInit()/UpnpFinish() 
> to check for general stability, which is also always a good test for 
> software cleanliness according to my experience; unfortunately, this 
> immediately resulted in the access violation in PTW32.
>
> It looks like libupnp still has to adapt to the changed calling 
> behavior of PTW32, although they had plenty of time for it (the latest 
> libupnp release is from January 2013, while the latest PTW32 is from 
> May 2012). They probably overlooked the change in calling 
> pthread_win32_process_*; I will send them a note for it.
>
> Nevertheless, I will continue to use my locally patched version of 
> PTW32 until either libupnp adapted to the changed PTW32 behavior or 
> PTW32 is available with initialization of globals during the attaching 
> phase. I've ran into the same problem in some of my libraries too, and 
> decided to give my globals a proper initialization in an 
> Init()-function to avoid such issues during repeated 
> de-/initialization. It would be nice if you could consider doing this 
> in PTW32 too, just for the sake of backwards-compatibility (if this 
> actually worked in pre-2.9.0 versions).
>
> Best regards,
> Klaus
>
>
> > 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