public inbox for
 help / color / mirror / Atom feed
From: Klaus Fischer <>
Subject: Re: Crash when re-initializing as static library
Date: Thu, 07 Nov 2013 14:19:00 -0000	[thread overview]
Message-ID: <> (raw)

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,

 > 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

             reply	other threads:[~2013-11-07 14:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-07 14:19 Klaus Fischer [this message]
2013-11-07 23:47 ` Ross Johnson
2013-11-08 10:39   ` Klaus Fischer
2013-11-14 13:34     ` Klaus Fischer
  -- strict thread matches above, loose matches on Subject: below --
2013-11-06 17:53 Klaus Fischer
2013-11-06 23:17 ` Ross Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).