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

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

Corinna Vinschen wrote:
> On Aug 12 14:19, Dave Korn wrote:
>> Corinna Vinschen wrote:
>>> On Aug 12 02:14, Dave Korn wrote:
>>>> Corinna Vinschen wrote:
>>>>   Yes, this is a real problem.  It's 2am over here; I'll get onto it in the
>>>> morning.  Sorry for the inconvenience; I really didn't expect people to try to
>>>> unload their override of a vital library function at runtime and still expect it
>>>> to work!
>>> Erm... hang on.  Neither the test application, not the test DLLs are
>>> C++ applications.  It's all pure C.  The problem, afaics is, that
>>> this statement:
>>>   if (newu)
>>>     newu->cxx_malloc = &__cygwin_cxx_malloc;
>>> will *always* replace the cxx_malloc pointer with the one from the just
>>> loaded DLL, even if the DLL doesn't *have* any C++ malloc overrides.
>>   I said it was 2am.  Yes, that is the problem.
>>>  Maybe the code should be changed to check first if at least one of the
>>> existing pointers is about to be replaced, or, in other words, if at
>>> least one of the pointers in __cygwin_cxx_malloc is != NULL.
>>> Or, what if not cxx_malloc is changed, but rather the content, along these
>>> lines:
>>>   if (newu)
>>>     *newu->cxx_malloc = __cygwin_cxx_malloc;
>>   Yes, this is the approach I would like to take.  Sorry all, I had a long sleep
>> but I'm on it now.  Expect patches during the afternoon.
> Did you see my preliminary patches for a start?

  Yep, thank you, figure we'll need to combine always updating the default
in-DLL malloc struct with saving and restoring the pointer and copying back the
updated entries if loading an old DLL that changes the pointer.  That's what I'm
coding, anyway.


More information about the Cygwin-developers mailing list