[PATCH v3] dlfcn: Fix dlclose crash in atexit handler after thread_local destructor (BZ 33598)

[Adhemerval Zanella Netto]

On 05/05/26 18:35, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> However, analyzing this a bit more I am not sure. With DL_UNMAP the
>> link map is still removed from the namespace, but the pages remain
>> mapped and the DSO is gone from GL(dl_ns[nsid]._ns_loaded),
>> _dl_loaded_lock, and l_initfini chains. This creates an inconsistent
>> state where:
>>
>> * This approach guarantees that _dl_fini runs all fini/fini_array
>> callbacks in a single topologically-sorted pass, where DL_UNMAP
>> _dl_close_worker's _dl_call_fini may run destructors for a library
>> during exit, and then _dl_fini may encounter it again (or not, if
>> the link map was removed).
> 
> I'm not sure the explanation in the commit message that this prevents
> unmapping only is correct.  I think it does alter destructor ordering
> in some cases.
> 
> We likely have applications that depend on dlclose actually running
> destructors during exit.  These regressions would only concern
> application exit, so hopefully they are not critical, but the change
> still seems rather invasive.  My past attempts to tweak the
> destruction order have surfaced lots of issues, so I think we should
> avoid that if we can.
> 
> I need to think more about this.  Maybe I'm misunderstanding the
> nature of this bug.

I have not considered keeping the destructor ordering the same, but I think
it should be feasible. I am not sure which is the expected behavior, this is
really an implementation detail where static class destructor interfere with
DSO destructor.

Let me check if it would be possible to keep the destructor ordering, I really
think we should not hack the unmap way to avoid potential semantic changes
on debugger/analyzers/sanitizers.