[Bug nptl/25847] pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing

fweimer at redhat dot com sourceware-bugzilla@sourceware.org
Fri Apr 18 10:43:19 GMT 2025


https://sourceware.org/bugzilla/show_bug.cgi?id=25847

--- Comment #74 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to yangyanchao6@huawei.com from comment #73)
> Is there any plan to incorporate this fix into earlier versions?

I'm concerned about immediate breakage of applications that use process-shared
condition variables in mapped files. In the past, condition variable changes
have broken RPM due to its use of Berkeley DB. That's why I'm leaning towards
distributions making an assessment whether they can incorporate this change.

Any backport should drop

commit c36fc50781995e6758cae2b6927839d0157f213c
Author: Malte Skarupke <malteskarupke@fastmail.fm>
Date:   Wed Dec 4 07:56:38 2024 -0500

    nptl: Remove g_refs from condition variables

    This variable used to be needed to wait in group switching until all
sleepers
    have confirmed that they have woken. This is no longer needed. Nothing
waits
    on this variable so there is no need to track how many threads are
currently
    asleep in each group.

    Signed-off-by: Malte Skarupke <malteskarupke@fastmail.fm>
    Reviewed-by: Carlos O'Donell <carlos@redhat.com>

so that

commit dbc5a50d12eff4cb3f782129029d04b8a76f58e7
Author: Florian Weimer <fweimer@redhat.com>
Date:   Thu Mar 13 06:07:07 2025 +0100

    nptl: PTHREAD_COND_INITIALIZER compatibility with pre-2.41 versions (bug
32786)

    The new initializer and struct layout does not initialize the
    __g_signals field in the old struct layout before the change in
    commit c36fc50781995e6758cae2b6927839d0157f213c ("nptl: Remove
    g_refs from condition variables").  Bring back fields at the end
    of struct __pthread_cond_s, so that they are again zero-initialized.

    Reviewed-by: Sam James <sam@gentoo.org>

isn't needed (and use of condition variables does not tricker ABI change
warnings in external code).

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Glibc-bugs mailing list