https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285870
--- Comment #6 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=23427c8e1fedb9fc68ad0bd27a59c7ffd2b3008c commit 23427c8e1fedb9fc68ad0bd27a59c7ffd2b3008c Author: Aurélien Croc de Suray <free...@ap2c.com> AuthorDate: 2025-04-05 00:47:53 +0000 Commit: Kyle Evans <kev...@freebsd.org> CommitDate: 2025-04-05 00:47:53 +0000 libc: allow __cxa_atexit handlers to be added during __cxa_finalize science/dlib-cpp reveals an interesting scenario that works fine on other platforms but not on FreeBSD; notably, it ends up creating a new global object from some destructor which is called during __cxa_finalize. This breaks when libdlib is dlopen()ed and then subsequently dlclose()ed, as we never end up invoking the created object's dtor until program exit when the shlib is already unmapped. Fix it by noting when we're in the middle of __cxa_finalize for a dso, and then restarting the search if __cxa_atexit() was called in the middle somewhere. We wait until we've processed the initial set before starting over and processing the newly added handlers as if it were a complete set of handlers added during runtime. The alternative is calling them as they're added to maintain a LIFO in terms of total ordering, but in theory a constructor could add another global object that also needs to be destroyed, and that object needs to be destroyed after the one that constructed it to avoid creating unexpected lifetime issues. This manifests in the pdlib PHP extension for dlib crashing, see [0]. [0] https://github.com/goodspb/pdlib/issues/39 PR: 285870 Reviewed by: kevans (also supplied commit message) MFC after: 1 week lib/libc/stdlib/atexit.c | 61 ++++++++++++++++++++++++++++-------------------- 1 file changed, 36 insertions(+), 25 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
