This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [Fwd: dlopen regression in 1.7? (or is it just me?)]
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!
> AFAICS this mechanism can't work reliable for dynamically loaded DLLs
> since they could be dlclosed at any given time. There must be a
> mechanism which works sort of like a linked list of cxx_malloc
> structures. And then again, how often is it allowed to override
> the cxx_malloc pointers at all? Is it really correct that any
> arbitrary DLL can install another set of cxx_malloc methods? I have
> some doubts...
The golden rule, as far as the gABI (substitute cxx-abi, SysV ABI; they are
all inter-related and descended from each other) is concerned, is that the sum
total of an exe + loaded DSOs should behave exactly the same as the equivalent
statically-linked program.
That is obviously underspecified w.r.t. dlclose(), as there's no equivalent
concept in a statically-linked exe to "part of your code suddenly disappears".
So I don't think there should even _be_ a malloc override in a library that's
liable to be dlclosed at runtime; it's really wrong to temporarily load or
prematurely unload something that overrides one of the vital malloc operators,
and I don't suppose it works well on Linux either. If it does have some way of
avoiding this problem we could probably adopt it, otherwise I imagine I need to
add some kind of malloc override deregistration routine to go alongside the way
they all register their overrides at startup.
Anyway, as I said it's 2am and I plan to get back onto a regular day/night
schedule tonight, so I'll look at this in the morning. Thanks for the heads-up.
cheers,
DaveK