From d9a348d0927c7a1aec5caf3df3fcd36956b3eb23 Mon Sep 17 00:00:00 2001 From: Davide Cavalca Date: Thu, 31 Jul 2025 17:32:58 +0200 Subject: [PATCH] stdlib: resolve a double lock init issue after fork [BZ #32994] The __abort_fork_reset_child (introduced in d40ac01cbbc66e6d9dbd8e3485605c63b2178251) call resets the lock after the fork. This causes a DRD regression in valgrind (https://bugs.kde.org/show_bug.cgi?id=503668), as it's effectively a double initialization, despite it being actually ok in this case. As suggested in https://sourceware.org/bugzilla/show_bug.cgi?id=32994#c2 we replace it here with a memcpy of another initialized lock instead, which makes valgrind happy. Reviewed-by: Florian Weimer --- stdlib/abort.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/stdlib/abort.c b/stdlib/abort.c index caa9e6dc04..904244a2fb 100644 --- a/stdlib/abort.c +++ b/stdlib/abort.c @@ -19,6 +19,7 @@ #include #include #include +#include #include /* Try to get a machine dependent instruction which will make the @@ -42,7 +43,10 @@ __libc_rwlock_define_initialized (static, lock); void __abort_fork_reset_child (void) { - __libc_rwlock_init (lock); + /* Reinitialize lock without calling pthread_rwlock_init, to + avoid a valgrind DRD false positive. */ + __libc_rwlock_define_initialized (, reset_lock); + memcpy (&lock, &reset_lock, sizeof (lock)); } void -- 2.47.2