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?)]
On Aug 12 17:16, Corinna Vinschen wrote:
> 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?
...especially considering that the application could have called new
before calling dlopen, then it calls new after dlopen and another
mechanism takes place, and after dlclose it's either the one from the
application itself (from the statically linked DLLs), or from one of the
other dlopened DLLs. And which one if there are 10 of them? Which one
has precedent? Or, consider a situation where the new operator of a
dlopened DLL allocates memory in a static memory region in its own
data segment for whatever reason. The application will have a pointer
pointing into nirvana again if that DLL is dlclosed.
*Shudder*
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat