Re: [PATCH v3] elf: Release dl_load_lock before running dlopen constructors (BZ 15686)

21.07.2026 16:44, Carlos O'Donell:
> ...
>
> However, I would like to discuss destructors too, and if anything
> needs to be done there.
>
> ....
> The scope makes sense, but I'm also concerned about destructors since
> both see this kind of problem. What prevents us from providing the same
> invariant in destructors?
> ...

I spent some time thinking about the destructor.

Even if I start adapting it for the destructor just by analogy, I don't
really understand what to test it on or how to verify it.
Maybe I could try to create an artificial problem: for example, the
destructor frees resources and removes them from a table
protected by a mutex. It wants to acquire the mutex. However, the
person holding the mutex has made a dlopen, and they have
caught each other.


A good solution I see is to fix the inconsistency at exit and at dlclose.
The asymmetry in behavior seems like a strange decision. From the
point of view of the semantics of the destructor, it is good to have
the same behavior in both cases. I suggest bringing dlclose to the
level of security that exit already provides.


However, this seems to be an additional task and it would be more
correct to make a separate commit 3/3

And it will turn out:
1/3 - constructor v4 + tests
2/3 - _dl_debug_printf
3/3 - destructor + test

Thanks,
Artem