From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7101 invoked by alias); 6 Nov 2013 17:53:39 -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 7088 invoked by uid 89); 6 Nov 2013 17:53:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=BAYES_50,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: relay.vianetworks.de Received: from Unknown (HELO relay.vianetworks.de) (194.231.55.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 06 Nov 2013 17:53:37 +0000 Received: from smtp.tara-systems.de (smtp.tara-systems.de [194.77.63.148]) (authenticated bits=0) by relay.vianetworks.de (8.14.4/8.14.4) with ESMTP id rA6HrPfv036767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 6 Nov 2013 18:53:26 +0100 (CET) (envelope-from klaus.fischer@tara-systems.de) Received: from [172.16.0.141] (pat37.tara.intern [172.16.10.236]) by smtp.tara-systems.de (Postfix) with ESMTP id 623B13CA for ; Wed, 6 Nov 2013 18:53:25 +0100 (CET) Message-ID: <527A8215.4010309@tara-systems.de> Date: Wed, 06 Nov 2013 17:53:00 -0000 From: Klaus Fischer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: pthreads-win32@sourceware.org Subject: Crash when re-initializing as static library Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013/txt/msg00020.txt.bz2 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 -- _________________________________________________________ Dipl. Inf. Klaus FISCHER - Software Engineer mailto: klaus.fischer@tara-systems.de _________________________________________________________