From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8874 invoked by alias); 6 Nov 2013 23:17:41 -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 8788 invoked by uid 89); 6 Nov 2013 23:17:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: icp-osb-irony-out8.external.iinet.net.au Received: from Unknown (HELO icp-osb-irony-out8.external.iinet.net.au) (203.59.1.225) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Nov 2013 23:17:38 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAITNelLKN5yE/2dsb2JhbABbgwe9PYJ6gScWdIIlAQEFOBsbBgQRCw0LCRYPCQMCAQIBRRMIAQGHfL8Vj2AWhBoDnkkniyaDOg Received: from unknown (HELO mail06.grapevine.net.au) ([202.55.156.132]) by icp-osb-irony-out8.iinet.net.au with ESMTP; 07 Nov 2013 07:17:29 +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 1VeCLo-00004r-LQ for pthreads-win32@sourceware.org; Thu, 07 Nov 2013 10:17:28 +1100 Message-ID: <527ACE08.7030409@homemail.com.au> Date: Wed, 06 Nov 2013 23:17:00 -0000 From: Ross Johnson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: pthreads-win32@sourceware.org Subject: Re: Crash when re-initializing as static library References: <527A8215.4010309@tara-systems.de> In-Reply-To: <527A8215.4010309@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/msg00021.txt.bz2 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 >