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

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;

Of course only from statically linked DLLs.  That way you will never
bend the cxx_malloc pointer storage into one of the later loaded DLLs,
rather it always resides within the Cygwin DLL.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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