Bug#1132468: libc6: pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing

Hi Florian,

On 2026-04-08 11:11, Florian Bezdeka wrote:
> Hi Aurelien,
> 
> On Tue, 2026-04-07 at 21:44 +0200, Aurelien Jarno wrote:
> > 
> > At this stage I am not fully convinced:
> > 
> > - It is not clear to me which software is currently affected by this 
> >   bug, and thus it's difficult to judge how important is it to fix this 
> >   bug, especially given this is not a regression from bullseye (the bug 
> >   is present in that version). Do you have some real examples of 
> >   affected software that can show it's important to fix this bug in 
> >   bookworm?
> 
> That's hard to tell. I'm quite sure that there are Debian package
> affected by this problem but the "lockup" isn't happening that often, so
> that those problems likely stay unreported.
> 
> In our case the 3rd party application is based on the libace, which is
> also part of Debian. libace is implementing a thread pool based on
> condition variables. AFAIK the infrastructure around ACE_Task. Threads
> don't wake up when there is some work to do. 
> 
> I'm quite sure the same pattern is implemented within other Debian
> packages as well.

Ok, thanks for the details. I have noticed that libace does not have any 
packages depending on it. It would be interested to known if any other 
package in the archive suffer from the same issue.

> > - As said above, there is a risk of breakage, which many users would not 
> >   expect now that bookworm is 2+ years old. The bookworm to trixie 
> >   upgrade, is different because users expect some breakages for such a 
> >   major upgrade and as it is a major glibc upgrade, services were 
> >   restarted and systems are often rebooted afterwards.
> 
> Valid point. See below. Maybe we can do something on the testing side?

The problem is to identify software that might be broken by the fix, 
then testing is the easy part.

From what I understand from the upstream bug log, at least packages 
using db5.3 have a risk to get broken when upgrading to the fixed glibc, 
unless they are restarted (that's the reason why it's an issue on RPM 
based distributions). The db-5.3.28-condition_variable.patch should fix 
that, but it is not applied in the debian db5.3 package (not even in 
unstable). It applies cleanly though.

> > - We have fewer autopkgtest in bookworm than for trixie, which reduces 
> >   the chances of catching regressions before they reach a point release.
> > 
> > In the end we'll need to convince the release team that the bug is 
> > important to fix and there is minimal risk to include it in a point 
> > release.
> > 
> > In any case I would prefer to avoid including this in the next bookworm 
> > point release (12.14, scheduled for 16 May) as there are already 5 CVE 
> > (+1 pending) to be fixed win this update. I would prefer to avoid the 
> > risk of delaying the glibc update to the next point release in case an 
> > issue is found.
> 
> Can we do something on the testing side to get better confidence?
> 
> We're internally stressing the patched glibc package for a couple of
> days now. The update path was also part of that testing, but for sure we
> can't cover all possible scenarios.
> 
> Normally a package would go through the unstable -> testing -> stable
> chain, which is not possible here because the bug is already fixed in
> newer releases. Could we use something like "proposed updates" to get
> additional feedback, so that we could consider this update for the next
> + 1 point release?
> 
> Any other ideas?

Yes, packages go through -proposed-updates before going to (old-)stable 
for a point release. But far less people are using that than testing, so 
I am not sure about the coverage we'll get. But if we decide to apply 
the patch series, we need to do that just after the point release to 
increase the testing time and the chance to catch issues.

> The upstream bug report mentions a couple of other 3rd party software
> now implementing a workaround for that issue. Broadcasting the condition
> variable, waking up all threads where n-1 threads go to sleep again
> immediately. This is a big performance penalty in case a lot of threads
> are involved.

Yes, the bug has attracted many different people, showing that the bug 
is not a corner case but a real issue. I just don't want to fix a bug to 
open a different one, so at this stage I am not sure what to do.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[email protected]                     http://aurel32.net