Lobsters | 📄 原文链接 | 2026-10-26 收录

glibc 一次重构怎样悄悄弄坏 Chromium 的声音

来源：refi64.dev — 2021（原文）

📋 概述

作者把 Chromium Flatpak 的 runtime 从 20.08 升到 21.08，第二天就被一个 PR 要求回滚：YouTube 完全放不出声音，音频服务报 futex 错误。他拿到 core dump 顺着栈回溯摸到 PulseAudio 的条件变量等待，再逐帧对比 glibc 2.31 到 2.33 的改动，定位到一个「清理重复代码」的提交——它让没有超时的条件变量等待也开始把 clockid=0（即 CLOCK_REALTIME）传给 futex_time64，于是每次调用都带上 FUTEX_CLOCK_REALTIME 标志，而 Chromium 的 BPF 沙箱只剥掉 FUTEX_PRIVATE_FLAG，把合法调用判成了 EPERM。

🔑 核心要点

触发链很清楚：Flatpak runtime 21.08 把 glibc 从 2.31 升到 2.33，音频服务随即崩溃，视频播不动
崩溃日志里的 The futex facility returned an unexpected error code 来自 glibc 的 __libc_fatal，不是 Chromium 自己打的
只有 Chromium 中招、Chrome/Brave/Edge 正常，因为只有 Chromium 开着 AudioServiceSandboxLinux 这条灰度试验
glibc 那个提交本意是删掉 futex_wait_cancelable 这条重复路径，结果让 clockid 在没有超时时也被使用，而 0 恰好等于 CLOCK_REALTIME
Chromium 沙箱白名单只做了 op & ~FUTEX_PRIVATE_FLAG，没剥 FUTEX_CLOCK_REALTIME，op 值对不上，于是放行变成 EPERM
沙箱本身是两层结构：先限制进程运行环境，再用 BPF 过滤系统调用，不在白名单的调用一律拒绝
修复只有一行改动，作者感叹最离谱的 bug 往往修起来最简单

💡 金句

glibc 2.33, as part of a code refactoring, unintentionally started passing the flag FUTEX_CLOCK_REALTIME to every futex_time64 syscall when waiting on condition variables.

← 返回 Lobsters 首页