From f8e9545f700a4e3799bbac4cd1c94989b9c1fb61 Mon Sep 17 00:00:00 2001 From: Olivier Houchard Date: Thu, 17 Jul 2025 19:27:39 +0200 Subject: [PATCH] BUG/MEDIUM: threads: Disable the workaround to load libgcc_s on macOS Don't use the workaround to load libgcc_s on macOS. It is not needed there, and it causes issues, as recent macOS dislike processes that fork after threads where created (and the workaround creates a temporary thread). This fixes crashes on macOS at least when using master-worker, and using the system resolver. This should fix Github issue #3035 This should be backported up to 2.8. --- src/thread.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/thread.c b/src/thread.c index 16d087b83..4fc7402ea 100644 --- a/src/thread.c +++ b/src/thread.c @@ -1213,6 +1213,7 @@ int pthread_rwlock_unlock(pthread_rwlock_t *rwlock) } #endif // defined(USE_PTHREAD_EMULATION) +#ifndef __APPLE__ /* Depending on the platform and how libpthread was built, pthread_exit() may * involve some code in libgcc_s that would be loaded on exit for the first * time, causing aborts if the process is chrooted. It's harmless bit very @@ -1233,12 +1234,15 @@ static inline void preload_libgcc_s(void) if (pthread_create(&dummy_thread, NULL, dummy_thread_function, NULL) == 0) pthread_join(dummy_thread, NULL); } +#endif static void __thread_init(void) { char *ptr = NULL; +#ifndef __APPLE__ preload_libgcc_s(); +#endif thread_cpus_enabled_at_boot = thread_cpus_enabled(); thread_cpus_enabled_at_boot = MIN(thread_cpus_enabled_at_boot, MAX_THREADS); -- 2.47.3