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
