X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <4B66EB9C.80308@gmail.com>
Date: Mon, 01 Feb 2010 14:56:28 +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: dlclose not calling destructors of static variables.
References: <4B61732F DOT 4030804 AT gmail DOT com>  <4B62DDE6 DOT 5070106 AT gmail DOT com>  <4B62F118 DOT 8010305 AT gmail DOT com> <20100129184514 DOT GA9550 AT ednor DOT casa DOT cgf DOT cx> <4B66BF2F DOT 4060802 AT gmail DOT com>
In-Reply-To: <4B66BF2F.4060802@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 01/02/2010 11:46, Andrew West wrote:

> I checked out the changes and it still crashed for me. Digging into it
> the destructor for testlib fell outside of dll_end ( m.AllocationBase +
> m.RegionSize ). On a whim I change m.AllocationBase to m.BaseAddress and
> that seemed to fix it for me! The destructor ran on dlclose and the
> testrunner.exe didn't segfault.

  As promised, I'm working on the other half of this problem.

> On 29/01/2010 18:45, Christopher Faylor wrote:
> 
>> I agree with your assessment here.  I've checked in a change which works
>> around the problem you've uncovered but it is not foolproof.  

  It's definitely the right thing to do, we'll need it for a while to support
any existing DLLs with ctors.  (We did touch on this whole area briefly back
when sorting out the mallocwrapper stuff w.r.t dlopen/close, and I looked at
it briefly then but we were trying to stabilise for 1.7.1 at the time.)

  Doesn't remove_dll_atexit() need some locking, though?

> It should
>> fix the immediate problem but, in the long run, I agree that gcc should
>> be emitting code which calls __cxa_atexit.  Of course I have no idea
>> what the other ramifications of doing that might be.  Hopefully Dave can
>> enlighten us.

  I'm doing a patch this afternoon to add the necessary support in the DLL and
CRT.  Once that's in, people could start using it straight away by adding
"-fuse-cxa-atexit" in their CFLAGS, and I'll be building a new release of the
compiler with it on by default (need to fix those script perms and the java
alternatives anyway, so I'll do them all in one).

  The ramifications, such as they are, are that newly-built user DLLs won't
run against old versions of the Cygwin DLL, which is just the usual thing
anyway.  Old user DLLs will initially continue to have this limit to the
correctness of their function.  For the third part of the fix, I'm going to
try something a bit more tricky: if we can detect in cygwin_atexit() whether
we're being called from a DLL, we can fabricate a __dso_handle value and
redirect to cxa_atexit.

    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