This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [Fwd: dlopen regression in 1.7? (or is it just me?)]
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Tue, 11 Aug 2009 20:21:34 +0200
- Subject: Re: [Fwd: dlopen regression in 1.7? (or is it just me?)]
- References: <20090811180200.GJ3204@calimero.vinschen.de>
- Reply-to: cygwin-developers at cygwin dot com
On Aug 11 20:02, Corinna Vinschen wrote:
> Hi Dave,
>
> did you see this very fresh mail on the Cygwin list?
> http://cygwin.com/ml/cygwin/2009-08/msg00352.html
>
> ----- Forwarded message from Peter Rosin -----
> > Date: Tue, 11 Aug 2009 18:57:36 +0200
> > From: Peter Rosin <schubidu>
> > Subject: dlopen regression in 1.7? (or is it just me?)
> > To: cygwin ML
> >
> > Hi!
> >
> > I trouble with dlopen in cygwin-1.7
> >
> > STC:
> > [...]
> > $ ./reload
> > one 0x63d80000, two 0x6ffc0000
> > one 0x0, two 0x6ffc0000
> ----- End forwarded message -----
>
> I debugged this a bit to find out what happens. I don't understand
> exactly what's going on, but the reason for the failing dlopen is a
> crash in _cygwin_crt0_common, line 124. That's the first of the
> CONDITIONALLY_OVERRIDE macros. When I link the simple1.dll and
> simple2.dll files against a debug version of libcygwin.a (otherwise you
> don't see the line number information) it crashes at this point with a
> SIGSEGV. Examining newu, it turns out that the cxx_malloc member points
> into an address space not yet allocated:
>
> (gdb) p newu
> $1 = (per_process *) 0x6116b2c0
> (gdb) p *newu
> $2 = {initial_sp = 0x22ff68 "\210ÿ\"", magic_biscuit = 168, dll_major = 1007,
> dll_minor = 0, impure_ptr_ptr = 0x6116fcc0, envptr = 0x404028,
> malloc = 0x4015c0 <malloc>, free = 0x4015c8 <free>,
> realloc = 0x4015d0 <realloc>, fmode_ptr = 0x40402c, main = 0x4010f0 <main>,
> ctors = 0x401610, dtors = 0x40161c, data_start = 0x402000,
> data_end = 0x4020ac, bss_start = 0x404000, bss_end = 0x404050,
> calloc = 0x4015d8 <calloc>, premain = {0x401580 <cygwin_premain0>,
> 0x401590 <cygwin_premain1>, 0x4015a0 <cygwin_premain2>,
> 0x4015b0 <cygwin_premain3>}, run_ctors_p = 0, unused = {0, 0, 0, 0, 0, 0,
> 0}, cxx_malloc = 0x67d42020, hmodule = 0x400000, api_major = 0,
> api_minor = 212, unused2 = {0, 0, 0, 0, 0, 0},
> threadinterface = 0x611f02a8, impure_ptr = 0x6116fce0}
> (gdb) p *newu->cxx_malloc
> Cannot access memory at address 0x67d42020
>
> Since that only occurs on the second invocation of dlopen for the
> same file, is it possible that there's some old information hanging
> around?
I think I understand what's going on. On dlopen, the cxx_members
are conditionally overridden and then the global newu->cxx_malloc
pointer gets replaced with the address of __cygwin_cxx_malloc in
the just loaded DLL. If you load another DLL, the same happens again.
If you dlclose (== FreeLibrary) the second DLL, newu->cxx_malloc points
into nirvana.
AFAICS this mechanism can't work reliable for dynamically loaded DLLs
since they could be dlclosed at any given time. There must be a
mechanism which works sort of like a linked list of cxx_malloc
structures. And then again, how often is it allowed to override
the cxx_malloc pointers at all? Is it really correct that any
arbitrary DLL can install another set of cxx_malloc methods? I have
some doubts...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat