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

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Wed Aug 12 16:11:00 GMT 2009

On Wed, Aug 12, 2009 at 12:08:08PM -0400, Christopher Faylor wrote:
>On Wed, Aug 12, 2009 at 05:16:00PM +0200, 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.
>Right, but couldn't you store/restore this in the per-dll structure?

Which is already a linked list, btw.

In case anyone cares.


More information about the Cygwin-developers mailing list