X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Wed, 24 Feb 2010 02:23:35 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Statically initialising pthread attributes in dynamic dlls. Message-ID: <20100224072335.GA4085@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B848353.2010209@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 Wed, Feb 24, 2010 at 01:39:31AM +0000, Dave Korn wrote: >On 24/02/2010 00:44, Christopher Faylor wrote: > >> I never saw the cygwin exception handler on the list twice when I was >> debugging this. That isn't supposed to happen and I don't see how it >> could happen unless Windows is doing it since the code in >> _cygtls::init_exception_handler is supposed to prevent that and, if it >> was on the list twice bad stuff happened. >> >> That actually looks like a typo above since you seem to have typed the >> same address twice. >> >> Anyway, I've revisited this code, just like I knew I would, and have >> added YA in a long series of tweaks which seems to fix your particular >> problem. The fix is in the latest snapshot. > > :( I think I can see where the next problem is going to arise already. > > If we move el to the front of the list each time, what's going to happen >when we eventually return from LoadLibrary, and el.prev is still pointing at >the now-deallocated stack frames where LoadLibrary created its temporary >EXCEPTION_REGISTRATION structures ? Unless you can show that LoadLibrary isn't smart enough to clean up after itself in this scenario, I think it's a non-issue. cgf -- 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