Re: 11.0_BETA: glxinfo crashes with Segmentation fault

[Henryk Paluch <hpaluch%seznam.cz@localhost>]

Regarding:

On 12/18/25 19:37, Martin Husemann wrote:
> You can not portably use atexit() for a function from a shared library
> that you then dlclose() before exiting.
>
> Use a destructor function instead.

These places seem to permit atexit(3) in DSOs:

1. https://gnats.netbsd.org/18379

2. Bug references: 
https://web.archive.org/web/20030222125703/http://www.codesourcery.com/cxx-abi/abi.html#dso-dtor 
which mentions atexit(3) call

3. https://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/stdlib/atexit.c

Last point (3) - cvs log - clearly intents to support atexit(3) from DSO:

===========================
Revision 1.15:
Fix lib/20558:
A dynamically linked program invokes the rtld cleanup routine via
an atexit handler.  This rtld cleanup routine invokes _fini() for
shared libraries, which in-turn invoke __cxa_finalize() with their
DSO handle.  By luck, this happens to work okay for non-threaded
programs, but for a threaded program, this leads to deadlock (sometimes
manifested as an assertion failure, if the program didn't actually
create any threads).

Fixed by teaching __cxa_finalize() that it can be recursively invoked,
adjusting the handler list manipulation accordingly.
================================
Revision 1.14:
Rewrite atexit(3), and add support for __cxa_atexit()/__cxa_finalize(),
as specified by the C++ ABI for Itanium.  Despite the ABI document's name,
many of the items in it are implemented for other architectures.

See the following URL for a reference:

	http://www.codesourcery.com/cxx-abi/abi.html#dso-dtor

Fixes lib/18379 (from Joel Baker).
===========================

Also the code in lib/libc/stdlib/atexit.c function __cxa_finalize 
clearly expects to be called from DSO, but there is some bug in for loop:

for (prevp = &atexit_handler_stack; (ah = (*prevp)) != NULL;) {
// ...
}

That causes not finding DSO's atexit(3) - it skipped all data when I 
used gdb and therefore it postponed function call to global program exit 
(when DSO is no longer mapped) causing SIGSEGV).


We should understand what banning of atexit(3) from DSO will mean: That 
we will have to patch it in all places in NetBSD codebase (at least Mesa 
in 11Beta, but it is likely not only place) and also patch them in all 
affected pkgsrc packages - which is definitely not easy and lot of 
burden for future maintenance.


I'm not the one who has leverage to decide what is right or wrong:

1. Bug in __cxa_finalize that is unable to find registered callbacks
2. Or usage of atexit(3) from dlopen(3)/dlclose(3) shared libraries

But personally I think  that best approach would be to fix (1) and 
recommend to avoid (2) to cause least disruption to existing programs 
and pkgsrc packages (which we have no control of).

Regards
  --Henryk Paluch

On 12/18/25 19:37, Martin Husemann wrote:
> On Thu, Dec 18, 2025 at 07:27:51PM +0100, Henryk Paluch wrote:
> > I'm sorry but it is not bug in Mesa - thanks to RVP now we know for sure
> > that it is bug in handling atexit(3) call when invoked from shared libraries
> > via dlopen(3)/dlclose(3) calls. As demonstrated by RVP's example.
>
> You can not portably use atexit() for a function from a shared library
> that you then dlclose() before exiting.
>
> Use a destructor function instead.
>
> Martin