X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Message-ID: <4B856401.2000905@gmail.com> Date: Wed, 24 Feb 2010 17:38:09 +0000 From: Andrew West User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Statically initialising pthread attributes in dynamic dlls. References: <4B825D76 DOT 6000105 AT gmail DOT com> <4B82C093 DOT 7010001 AT gmail DOT com> <4B83A727 DOT 3030101 AT gmail DOT com> <4B841026 DOT 1000905 AT gmail DOT com> <20100224004403 DOT GA24591 AT ednor DOT casa DOT cgf DOT cx> <4B848353 DOT 2010209 AT gmail DOT com> <4B84B08C DOT 7060302 AT gmail DOT com> <4B84B887 DOT 6070801 AT gmail DOT com> In-Reply-To: <4B84B887.6070801@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 24/02/2010 05:26, Dave Korn wrote: > Yeh, that works nicely. Here's what I tested, along with a couple of extra > test cases I used to check whether exception handling was still working before > and after the dlopen call. With the current state of HEAD, the first one > works (by which I mean "prints 'sig 11' forever" and the second one fails (by > which I means reaches some sort of exit without hitting the signal handler at > all). With the attached diff, they both work (as does the original unmodified > testcase). > > This is just a brain dump because I'm off to bed now, hence no change log, > and there's still commented-out stuff and inadequate commenting, but I figured > I may as well let everyone know what I found out. 'night all! > > I've tried out the latest snapshots with the code that I originally found this bug with and it fixed the problem of being able to successfully call dlopen, but I seemed to run into what I think was a similar problem when I called dlclose. Unfortunately I can't seem to create a simple test case demonstrating this. If LoadLibrary could possibly remove the cygwin exception_handler isn't it possible that FreeLibrary could as well? I adding the line; _my_tls.init_exception_handler (_cygtls::handle_exceptions); To 'cygwin_detach_dll' before the 'dlls.detach' call and this seemed to fix the problem, but I'm not entirely sure of what the reprocusions of this might be. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple