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?)]


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?

You could check to see if the functions were redirected and restore them to
their previous...

Hmm.  No, if another dll had done something similar you'd get into
ordering problems.  Nevermind.  I think the best thing to do would be to
disallow this entirely.

>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?

Isn't that a problem for any DLL or any function that you could possibly
use?  There is always a possibility that, when you call a function, it
will have global side effects.  But, nevertheless, I think disallowing
this is the way to go.

cgf


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