https://bugs.kde.org/show_bug.cgi?id=503668
--- Comment #1 from Paul Floyd <pjfl...@wanadoo.fr> ---
Lookin at this it looks like it is a regression in glibc. Version 2.41 added
some locking around fork().
Without filtering the errors look like
==101957== Thread 3:
==101957== Reader-writer lock reinitialization: rwlock 0x4a71b60.
==101957== at 0x486191A: pthread_rwlock_init_intercept
(drd_pthread_intercepts.c:1734)
==101957== by 0x486191A: pthread_rwlock_init@*
(drd_pthread_intercepts.c:1742)
==101957== by 0x494CA6F: fork (fork.c:88)
==101957== by 0x4004EE: startproc (fork.c:18)
==101957== by 0x4848562: vgDrd_thread_wrapper (drd_pthread_intercepts.c:512)
==101957== by 0x48F91D3: start_thread (pthread_create.c:448)
==101957== by 0x497BB13: clone (clone.S:100)
==101957== rwlock 0x4a71b60 was first observed at:
==101957== at 0x4862ABA: pthread_rwlock_rdlock_intercept
(drd_pthread_intercepts.c:1798)
==101957== by 0x4862ABA: pthread_rwlock_rdlock@*
(drd_pthread_intercepts.c:1812)
==101957== by 0x4946CE4: _Fork (_Fork.c:31)
==101957== by 0x494CA1F: fork (fork.c:75)
==101957== by 0x4004EE: startproc (fork.c:18)
==101957== by 0x4848562: vgDrd_thread_wrapper (drd_pthread_intercepts.c:512)
==101957== by 0x48F91D3: start_thread (pthread_create.c:448)
==101957== by 0x497BB13: clone (clone.S:100)
Looking at the source for that, the creation of the phtread_rwlock looks like
internal_sigset_t original_sigmask;
__abort_lock_rdlock (&original_sigmask);
which is calling into this code
__libc_rwlock_define_initialized (static, lock);
void
__abort_lock_rdlock (internal_sigset_t *set)
{
internal_signal_block_all (set);
__libc_rwlock_rdlock (lock);
}
as always navigating the macros is non-obvious but I guess that comes from
#define __libc_rwlock_define_initialized(CLASS,NAME) \
CLASS __libc_rwlock_t NAME = PTHREAD_RWLOCK_INITIALIZER;
So the summary here is that pthread_rwlock_rdlock is being called using a file
static that is correctly initialized.
Then where the error occurs the code is
call_function_static_weak (__abort_fork_reset_child);
which does
void
__abort_fork_reset_child (void)
{
__libc_rwlock_init (lock);
}
Note that I don't see any intervening calls to pthread_rwlock_destroy.
The man page says
Results are undefined if pthread_rwlock_init() is called specifying an already
initialized read-write lock.
--
You are receiving this mail because:
You are watching all bug changes.
