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

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Christopher Faylor wrote:
> 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.

  Yep, I was thinking that we'd be able to walk through the list and find the
next DLL down and reinstate its overrides or something like that, but as pointed
out in the parallel parts of the thread by CV, that way madness lies and I'm
going with the no-overrides-at-runtime solution as being the best.

    cheers,
      DaveK