Incorrect order of calling destructors when unloading a dynamic library?

Question

linux

Hello,
I am facing a very strange problem.
I have a dynamic library on Linux that is dynamically loaded and unloaded by a process twice in a row (and I can't influence the logic of the process).
The first pair of calls to dlopen / dlclose work correctly - the destructors of static variables are called in the reverse order of their creation.
The second call to dlopen works fine. But the second (and all subsequent) call to dlclose leads to the fact that the destructors are called in the order of creation! At best, this goes unnoticed, but at worst, if one variable tries to use another, the process fails with SEGFAULT.
I tried to reproduce the problem with a small dummy dynamic library, but everything is ok there - no violations in the order of freeing static variables. The pass with LD_DEBUG did not reveal anything useful - dlclose / _fini are called regularly (sort of).
I then tried adding a few atexit() calls and seeing if the second dlclose() had any effect on them. It turned out that yes - their order is also violated (at first I thought that this only concerns C ++ finalization).
I didn't find a dependency on gcc version (tried 3.2/3.4/4.1.2) or Linux distributions (RHEL 4/5, SuSE 10). A Web search turned up no similar links.
In a real library (and it is very large), I have somewhat localized the part, the inclusion of which is starting to cause a problem, and I will still dig in this direction.
I would be grateful for any ideas - what else to try, what to read, where to look ...
Best regards,
Andrey

Answer 1

I've been fiddling around with debugging the atexit() code in GLIBC, and found that this is a bug in GLIBC - a fairly mundane bug that happens under fairly limited conditions.
I've been unlucky enough to hit exactly GLIBC 2.3.4, which has the bug. In the next version of GLIBC 2.4, it has already been fixed.

Answer 2

There was something similar. Do you happen to have this dynamic library not statically linked during assembly with some library, which is also statically linked from the binaries from which the dynamic library is loaded?
I had a similar problem, but it only appeared on a certain distribution.