This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]