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

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Aug 12 15:16:00 GMT 2009

On Aug 12 15:48, Dave Korn wrote:
> Corinna Vinschen wrote:
> > Of course, we could also kludge dlopen to workaround "broken" DLLs.
> > It could store the old cxx_malloc pointer before calling LoadLibrary and 
> > restore it afterwards.  This would allow us to stick with these DLLs.
> > 
> > I tested the below patch to dlopen.  It seems to work nicely for the
> > testcase sent by Peter.  Any drawbacks?
>   The only slight drawback is it means that you can't have a malloc override in
> a dlopen'd library, because it restores the pointer without copying back the
> updated set of overrides from the library's internal struct that the pointer now
> points at.
>   Of course that's good because it means you can't dlclose it and suddenly have
> operator new disappear, but it might be a nice feature.  To make it work, we'd
> need to maintain a stack of override entries, so that at dlclose time we could
> restore the previous set of overrides.  I'm just pondering if we can figure out

A stack wouldn't help since the dlclose calls can be in arbitrary order.
And there's something else which speaks agains supporting overriding new
in dlopened libs.  Consider this scenario:

  dlopen(lib1)  Installs own new
  dlopen(lib3)  Installs own new

At this point the new of lib2 will be used for any further call.
But what if lib1 expects that *its* new is used?  Isn't the entire
idea to support dynamically overridable allocators quite dangerous?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list