From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8402 invoked by alias); 7 Nov 2013 23:47:38 -0000 Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org Received: (qmail 8393 invoked by uid 89); 7 Nov 2013 23:47:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.4 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPAM_SUBJECT,SPF_PASS autolearn=no version=3.3.2 X-HELO: icp-osb-irony-out1.external.iinet.net.au Received: from Unknown (HELO icp-osb-irony-out1.external.iinet.net.au) (203.59.1.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Nov 2013 23:47:36 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJMlfFLKN5yE/2dsb2JhbABagwe9IIJ7gSgWdIIlAQEFOBsbBgQRCw0LCRYPCQMCAQIBRRMIAQGHfL1IjgWBW4QwA5Qsih0niyaDOg Received: from unknown (HELO mail06.grapevine.net.au) ([202.55.156.132]) by icp-osb-irony-out1.iinet.net.au with ESMTP; 08 Nov 2013 07:47:27 +0800 Received: from [180.200.163.197] (helo=[192.168.2.2]) by mail06.grapevine.net.au with esmtp (Exim 4.77) (envelope-from ) id 1VeZIM-0004XC-LK for pthreads-win32@sourceware.org; Fri, 08 Nov 2013 10:47:26 +1100 Message-ID: <527C268D.8060003@homemail.com.au> Date: Thu, 07 Nov 2013 23:47:00 -0000 From: Ross Johnson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: pthreads-win32@sourceware.org Subject: Re: Crash when re-initializing as static library References: <527BA16A.3050404@tara-systems.de> In-Reply-To: <527BA16A.3050404@tara-systems.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013/txt/msg00023.txt.bz2 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