aboutsummaryrefslogtreecommitdiff
path: root/ntpsnmpd/(developers-only)
diff options
context:
space:
mode:
authorAurélien Croc de Suray <freebsd@ap2c.com>2025-04-05 00:47:53 +0000
committerKyle Evans <kevans@FreeBSD.org>2025-04-05 00:47:53 +0000
commit23427c8e1fedb9fc68ad0bd27a59c7ffd2b3008c (patch)
tree96a7b162b1bcaafd73ff6f32005a9351d3851193 /ntpsnmpd/(developers-only)
parent22fe926a62b7bca771d46502dd6a8c202f25b5be (diff)
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
Diffstat (limited to 'ntpsnmpd/(developers-only)')
0 files changed, 0 insertions, 0 deletions