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

Dave Korn dave.korn.cygwin@googlemail.com
Wed Aug 12 14:34:00 GMT 2009


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
how to do that with what we already have - the way each dll updates its internal
struct as we go through load order is almost that, but I'm not sure if we have
quite enough info to unwind it when e.g. a dlopen'd dll in the middle of the
chain is closed.

  Hmmm.  I'll think about this for a bit while testing the simpler solution of
disallowing overrides in dlopen'd dlls altogether.

    cheers,
      DaveK



More information about the Cygwin-developers mailing list