Re: [Fwd: dlopen regression in 1.7? (or is it just me?)]

[Corinna Vinschen <corinna-cygwin 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