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

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

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.


More information about the Cygwin-developers mailing list