delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
X-SWARE-Spam-Status: | No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 |
X-Spam-Check-By: | sourceware.org |
Message-ID: | <4B848353.2010209@gmail.com> |
Date: | Wed, 24 Feb 2010 01:39:31 +0000 |
From: | Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com> |
User-Agent: | Thunderbird 2.0.0.17 (Windows/20080914) |
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> |
In-Reply-To: | <20100224004403.GA24591@ednor.casa.cgf.cx> |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
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 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 ? I was thinking of adding a stack (possibly only two-level) instead of relinking the single el member to the front, but either way we have to find some way to unlink it again when the stack unwinds. cheers, DaveK -- 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |