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

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Aug 12 12:59:00 GMT 2009

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

  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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list