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


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]