标签: 问题解决记录 - ouuan's blog https://ouuan.moe/tag/%E9%97%AE%E9%A2%98%E8%A7%A3%E5%86%B3%E8%AE%B0%E5%BD%95 标签为 问题解决记录 的文章 - ouuan 的博客 Thu, 20 Mar 2025 14:18:09 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN Copyright © 2022 - 2026 ouuan Licensed under CC BY-SA 4.0 <![CDATA[修复 XeTeX 更新导致编译错误]]> https://ouuan.moe/post/2025/03/fix-xetex-update https://ouuan.moe/post/2025/03/fix-xetex-update Thu, 20 Mar 2025 14:18:09 GMT 毕设又咕了几周，今天一看编译出错（

]]> 毕设又咕了几周，今天一看编译出错（

This is XeTeX, Version 3.141592653-2.6-0.999997 (TeX Live 2025/Arch Linux) (preloaded format=xetex)
 restricted \write18 enabled.
---! /var/lib/texmf/web2c/xetex/xetex.fmt made by different executable version, strings are different
(Fatal format file error; I'm stymied)

tl;dr

sudo pacman -S texlive-xetex

问 GPT

先去问了下 GPT，它让我 sudo rm /var/lib/texmf/web2c/xetex/xetex.fmt 然后 sudo fmtutil-sys --all 或者 sudo fmtutil-sys --byfmt xetex。当然是没用的，因为此时我没有安装 texlive-xetex（

后来我自己发现问题了，但如果再告诉 GPT Did not find entry for byfmt=xetex skipped 应该可以省几分钟。

问题分析

首先是在 2023 年，Arch Linux 把 TeX Live 拆包了：TeX Live package reorganization。此事在我的 /var/log/pacman.log 中记载如下：

[2023-06-18T19:25:40+0800] [PACMAN] Running 'pacman -S texlive-binextra'
[2023-06-18T19:25:47+0800] [ALPM] transaction started
[2023-06-18T19:25:47+0800] [ALPM] installed texlive-binextra (2023.66594-11)
[2023-06-18T19:25:47+0800] [ALPM] transaction completed
[2023-06-18T19:25:47+0800] [ALPM] running '30-systemd-update.hook'...
[2023-06-18T19:25:47+0800] [ALPM] running '70-mktexlsr.hook'...
[2023-06-18T19:25:48+0800] [ALPM] running '72-texlive-fmtutil.hook'...
[2023-06-18T19:25:48+0800] [ALPM-SCRIPTLET] fmtutil [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).
[2023-06-18T19:36:40+0800] [PACMAN] Running 'pacman --noconfirm --color=always -Sy'
[2023-06-18T19:36:40+0800] [PACMAN] synchronizing package lists
[2023-06-18T19:36:42+0800] [PACMAN] Running 'pacman --color=always -Su'
[2023-06-18T19:36:42+0800] [PACMAN] starting full system upgrade
[2023-06-18T19:36:45+0800] [PACMAN] Running 'pacman -S texlive-xetex'
[2023-06-18T19:37:14+0800] [ALPM] transaction started
[2023-06-18T19:37:14+0800] [ALPM] installed texlive-xetex (2023.66594-11)
[2023-06-18T19:37:14+0800] [ALPM] transaction completed
[2023-06-18T19:37:14+0800] [ALPM] running '30-systemd-update.hook'...
[2023-06-18T19:37:14+0800] [ALPM] running '70-mktexlsr.hook'...
[2023-06-18T19:37:14+0800] [ALPM] running '72-texlive-fmtutil.hook'...
[2023-06-18T19:37:15+0800] [ALPM-SCRIPTLET] fmtutil [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).
[2023-06-18T19:38:30+0800] [PACMAN] Running 'pacman -Rns texlive-xetex'
[2023-06-18T19:38:31+0800] [ALPM] transaction started
[2023-06-18T19:38:31+0800] [ALPM] removed texlive-xetex (2023.66594-11)
[2023-06-18T19:38:32+0800] [ALPM] transaction completed
[2023-06-18T19:38:32+0800] [ALPM] running '30-systemd-update.hook'...
[2023-06-18T19:38:32+0800] [ALPM] running '70-mktexlsr.hook'...
[2023-06-18T19:38:32+0800] [ALPM] running '72-texlive-fmtutil.hook'...
[2023-06-18T19:38:32+0800] [ALPM-SCRIPTLET] fmtutil [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).
[2023-06-18T19:50:37+0800] [PACMAN] Running 'pacman --noconfirm --color=always -Sy'
[2023-06-18T19:50:37+0800] [PACMAN] synchronizing package lists
[2023-06-18T19:50:40+0800] [PACMAN] Running 'pacman --color=always -Su'
[2023-06-18T19:50:40+0800] [PACMAN] starting full system upgrade
[2023-06-18T19:50:43+0800] [PACMAN] Running 'pacman -S texlive-meta'
[2023-06-18T19:51:29+0800] [ALPM] transaction started
[2023-06-18T19:51:29+0800] [ALPM] installed texlive-bibtexextra (2023.66594-11)
[2023-06-18T19:51:29+0800] [ALPM] installed texlive-context (2023.66594-11)
[2023-06-18T19:51:37+0800] [ALPM] installed texlive-fontsextra (2023.66594-11)
[2023-06-18T19:51:37+0800] [ALPM] installed texlive-fontutils (2023.66594-11)
[2023-06-18T19:51:37+0800] [ALPM] installed texlive-formatsextra (2023.66594-11)
[2023-06-18T19:51:37+0800] [ALPM] installed texlive-games (2023.66594-11)
[2023-06-18T19:51:37+0800] [ALPM] installed texlive-humanities (2023.66594-11)
[2023-06-18T19:51:37+0800] [ALPM] installed texlive-luatex (2023.66594-11)
[2023-06-18T19:51:37+0800] [ALPM] installed texlive-metapost (2023.66594-11)
[2023-06-18T19:51:37+0800] [ALPM] installed texlive-music (2023.66594-11)
[2023-06-18T19:51:38+0800] [ALPM] installed texlive-plaingeneric (2023.66594-11)
[2023-06-18T19:51:38+0800] [ALPM] installed texlive-pstricks (2023.66594-11)
[2023-06-18T19:51:38+0800] [ALPM] installed texlive-publishers (2023.66594-11)
[2023-06-18T19:51:38+0800] [ALPM] installed texlive-xetex (2023.66594-11)
[2023-06-18T19:51:38+0800] [ALPM] installed texlive-meta (2023.66594-11)
[2023-06-18T19:51:38+0800] [ALPM] transaction completed
[2023-06-18T19:51:40+0800] [ALPM] running '30-systemd-update.hook'...
[2023-06-18T19:51:40+0800] [ALPM] running '70-mktexlsr.hook'...
[2023-06-18T19:51:42+0800] [ALPM] running '72-texlive-fmtutil.hook'...
[2023-06-18T19:51:43+0800] [ALPM-SCRIPTLET] fmtutil [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).
[2023-06-18T19:53:03+0800] [ALPM] running '73-texlive-updmap.hook'...
[2023-06-18T19:53:03+0800] [ALPM-SCRIPTLET] updmap [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).
[2023-06-18T19:54:14+0800] [PACMAN] Running 'pacman -Rns texlive-meta'
[2023-06-18T19:54:15+0800] [ALPM] transaction started
[2023-06-18T19:54:15+0800] [ALPM] removed texlive-meta (2023.66594-11)
[2023-06-18T19:54:16+0800] [ALPM] removed texlive-xetex (2023.66594-11)
[2023-06-18T19:54:16+0800] [ALPM] removed texlive-publishers (2023.66594-11)
[2023-06-18T19:54:16+0800] [ALPM] removed texlive-pstricks (2023.66594-11)
[2023-06-18T19:54:17+0800] [ALPM] removed texlive-plaingeneric (2023.66594-11)
[2023-06-18T19:54:17+0800] [ALPM] removed texlive-music (2023.66594-11)
[2023-06-18T19:54:17+0800] [ALPM] removed texlive-metapost (2023.66594-11)
[2023-06-18T19:54:17+0800] [ALPM] removed texlive-luatex (2023.66594-11)
[2023-06-18T19:54:18+0800] [ALPM] removed texlive-latexextra (2023.66594-11)
[2023-06-18T19:54:18+0800] [ALPM] removed texlive-latexrecommended (2023.66594-11)
[2023-06-18T19:54:18+0800] [ALPM] removed texlive-humanities (2023.66594-11)
[2023-06-18T19:54:18+0800] [ALPM] removed texlive-games (2023.66594-11)
[2023-06-18T19:54:18+0800] [ALPM] removed texlive-formatsextra (2023.66594-11)
[2023-06-18T19:54:18+0800] [ALPM] removed texlive-fontutils (2023.66594-11)
[2023-06-18T19:54:21+0800] [ALPM] removed texlive-fontsextra (2023.66594-11)
[2023-06-18T19:54:22+0800] [ALPM] removed texlive-context (2023.66594-11)
[2023-06-18T19:54:22+0800] [ALPM] removed texlive-bibtexextra (2023.66594-11)
[2023-06-18T19:54:22+0800] [ALPM] transaction completed
[2023-06-18T19:54:24+0800] [ALPM] running '30-systemd-update.hook'...
[2023-06-18T19:54:24+0800] [ALPM] running '70-mktexlsr.hook'...
[2023-06-18T19:54:24+0800] [ALPM] running '72-texlive-fmtutil.hook'...
[2023-06-18T19:54:24+0800] [ALPM-SCRIPTLET] fmtutil [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).
[2023-06-18T19:54:46+0800] [ALPM] running '73-texlive-updmap.hook'...
[2023-06-18T19:54:46+0800] [ALPM-SCRIPTLET] updmap [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).
[2023-06-18T19:55:28+0800] [PACMAN] Running 'pacman --noconfirm --color=always -Sy'
[2023-06-18T19:55:28+0800] [PACMAN] synchronizing package lists
[2023-06-18T19:55:30+0800] [PACMAN] Running 'pacman --color=always -Su'
[2023-06-18T19:55:30+0800] [PACMAN] starting full system upgrade
[2023-06-18T19:55:33+0800] [PACMAN] Running 'pacman -S texlive-latexrecommended'
[2023-06-18T19:55:34+0800] [ALPM] transaction started
[2023-06-18T19:55:34+0800] [ALPM] installed texlive-latexrecommended (2023.66594-11)
[2023-06-18T19:55:34+0800] [ALPM] transaction completed
[2023-06-18T19:55:34+0800] [ALPM] running '30-systemd-update.hook'...
[2023-06-18T19:55:34+0800] [ALPM] running '70-mktexlsr.hook'...
[2023-06-18T19:55:43+0800] [PACMAN] Running 'pacman --noconfirm --color=always -Sy'
[2023-06-18T19:55:43+0800] [PACMAN] synchronizing package lists
[2023-06-18T19:55:46+0800] [PACMAN] Running 'pacman --color=always -Su'
[2023-06-18T19:55:46+0800] [PACMAN] starting full system upgrade
[2023-06-18T19:55:48+0800] [PACMAN] Running 'pacman -S texlive-latexextra'
[2023-06-18T19:55:49+0800] [ALPM] transaction started
[2023-06-18T19:55:50+0800] [ALPM] installed texlive-latexextra (2023.66594-11)
[2023-06-18T19:55:50+0800] [ALPM] transaction completed
[2023-06-18T19:55:50+0800] [ALPM] running '30-systemd-update.hook'...
[2023-06-18T19:55:50+0800] [ALPM] running '70-mktexlsr.hook'...
[2023-06-18T19:55:50+0800] [ALPM] running '72-texlive-fmtutil.hook'...
[2023-06-18T19:55:51+0800] [ALPM-SCRIPTLET] fmtutil [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).
[2023-06-18T19:56:31+0800] [ALPM] running '73-texlive-updmap.hook'...

总之，拆包之后，我想看看需要装什么。发现有 texlive-xetex 就装了，之后又换成 texlive-meta，感觉太 bloat 了又卸了（

之后又安装卸载过两次：

[2023-06-22T21:28:40+0800] [PACMAN] Running 'pacman -S texlive-xetex'
[2023-06-22T21:32:05+0800] [ALPM] transaction started
[2023-06-22T21:32:05+0800] [ALPM] installed texlive-xetex (2023.66594-14)
[2023-06-22T21:32:06+0800] [ALPM] transaction completed
[2023-06-22T21:32:06+0800] [ALPM] running '30-systemd-update.hook'...
[2023-06-22T21:32:06+0800] [ALPM] running '70-mktexlsr.hook'...
[2023-06-22T21:32:06+0800] [ALPM] running '72-texlive-fmtutil.hook'...
[2023-06-22T21:32:06+0800] [ALPM-SCRIPTLET] fmtutil [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).
[2023-06-22T21:34:41+0800] [PACMAN] Running 'pacman -Rns texlive-xetex'
[2023-06-22T21:34:41+0800] [ALPM] transaction started
[2023-06-22T21:34:41+0800] [ALPM] removed texlive-xetex (2023.66594-14)
[2023-06-22T21:34:42+0800] [ALPM] transaction completed
[2023-06-22T21:34:42+0800] [ALPM] running '30-systemd-update.hook'...
[2023-06-22T21:34:42+0800] [ALPM] running '70-mktexlsr.hook'...
[2023-06-22T21:34:42+0800] [ALPM] running '72-texlive-fmtutil.hook'...
[2023-06-22T21:34:42+0800] [ALPM-SCRIPTLET] fmtutil [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).
[2024-03-28T20:11:14+0800] [PACMAN] Running 'pacman --noconfirm --color=always -Sy'
[2024-03-28T20:11:14+0800] [PACMAN] synchronizing package lists
[2024-03-28T20:11:27+0800] [PACMAN] Running 'pacman --color=always -Su'
[2024-03-28T20:11:27+0800] [PACMAN] starting full system upgrade
[2024-03-28T20:11:32+0800] [PACMAN] Running 'pacman -S texlive-xetex'
[2024-03-28T20:13:11+0800] [ALPM] transaction started
[2024-03-28T20:13:11+0800] [ALPM] installed texlive-xetex (2024.0-3)
[2024-03-28T20:13:11+0800] [ALPM] transaction completed
[2024-03-28T20:13:11+0800] [ALPM] running '30-systemd-update.hook'...
[2024-03-28T20:13:11+0800] [ALPM] running '70-mktexlsr.hook'...
[2024-03-28T20:13:13+0800] [ALPM] running '72-texlive-fmtutil.hook'...
[2024-03-28T20:13:13+0800] [ALPM-SCRIPTLET] fmtutil [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).
[2024-03-29T00:30:55+0800] [PACMAN] Running 'pacman -Rns texlive-xetex'
[2024-03-29T00:30:55+0800] [ALPM] transaction started
[2024-03-29T00:30:56+0800] [ALPM] removed texlive-xetex (2024.0-3)
[2024-03-29T00:30:57+0800] [ALPM] transaction completed
[2024-03-29T00:30:57+0800] [ALPM] running '30-systemd-update.hook'...
[2024-03-29T00:30:57+0800] [ALPM] running '70-mktexlsr.hook'...
[2024-03-29T00:30:59+0800] [ALPM] running '72-texlive-fmtutil.hook'...
[2024-03-29T00:31:00+0800] [ALPM-SCRIPTLET] fmtutil [WARNING]: resetting $HOME value (was /home/ouuan) to root's actual home (/root).

我印象中我曾经意外发现 /usr/bin/xetex 是 texlive-bin 里的，而 texlive-xetex 里是 /usr/bin/xetex-unsafe 和一些其他东西，而且 texlive-xetex 卸载掉之后当时还能正常使用，于是就卸掉了（

而在 texlive-source/texk/web2c/xetexdir/NEWS 中可以看到 XeTeX 的版本历史：

  • XeTeX 0.999997 (7 March 2025)
  • XeTeX 0.999996 (February 2024)
  • XeTeX 0.999995 (February 2023)

于是我正好在 0.999996 发布的时候重新安装了一次 XeTeX，不知道是巧合还是当时也遇到了类似的问题，不记得了。

pacman -Qo /var/lib/texmf/web2c 可以发现，这个目录（以及里面的文件）并不属于任何包，实际上是由 72-texlive-fmtutil.hook 生成的。安装了 texlive-xetex 后就会生成出 /var/lib/texmf/web2c/xetex/xetex.fmt 等文件，然后即使卸载掉也可以使用 xetex，但不会更新，等到需要更新就挂了。

所以不要随便 unbloat（就像 BLAFS 那样（

最后让我们再来欣赏一下这个版本号（

3.141592653-2.6-0.999997

]]> Arch Linux 问题解决记录 <![CDATA[解决使用 profile-sync-daemon 时 Firefox 开机启动报错]]> https://ouuan.moe/post/2024/05/psd-firefox-startup https://ouuan.moe/post/2024/05/psd-firefox-startup Fri, 24 May 2024 18:31:28 GMT 为了提升性能，更好地利用 RAM，我一直在使用 profile-sync-daemon，也经常在开机时遇到下面这个报错：

Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile.

之前都是把弹窗关掉手动重启一下，最近终于去研究了一下把它修了。

]]> 为了提升性能，更好地利用 RAM，我一直在使用 profile-sync-daemon，也经常在开机时遇到下面这个报错：

Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile.

之前都是把弹窗关掉手动重启一下，最近终于去研究了一下把它修了。

profile-sync-daemon

profile-sync-daemon 就是在启动时把 browser profile 从硬盘复制到内存盘，然后创建 symlink 到内存盘，并且在需要的时候写回硬盘，在浏览器运行过程中主要都是访问内存，从而减少硬盘访问，理论上可以提升性能、降低硬盘损耗。

总之如果内存用不完的话，用这个东西看起来不亏（其实我一开始就是因为有 32G 内存用不完去搜了一下如何利用内存才知道有这个工具（

探寻报错原因

在用了 profile-sync-daemon 后，在开机时我经常遇到下面这个报错：

弹窗：Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile.

单次处理这个问题非常简单，关掉弹窗重启 Firefox 即可。但每次都遇到还是很烦，时间久了我还是去研究了一下。

根据错误提示以及搜索结果，刚开机时又肯定不会有其他 Firefox 进程在跑，我一开始主要怀疑是 profile-sync-daemon 在关机前备份时出了问题，导致有 lock 之类的没有释放掉就备份了。

由于我手动处理的时候都是重启一下 Firefox，所以我尝试修复的时候一开始先是写了个脚本自动重启 Firefox，发现直接重启不行，又尝试用 xdotool / wmctrl 等待报错弹窗出现后再重启，发现成功与否不太稳定。而进一步地，我发现重启这个过程是不必要的，重点其实在于，要多等待一会儿。

于是我去观察了一下刚开机时 profile 的状态，终于发现了问题。刚开机时 profile directory 会被设为到 /dev/null 的 symlink，而在整个 profile 都复制到内存盘后才会替换为正确的 symlink，我的 profile 比较大（3GB），就需要好几秒。只不过 Firefox 给的错误提示非常具有误导性，它其实是无法从 /dev/null 正常读取 profile，这和 “already running” 完全不沾边。

问题修复

我的解决方案是写了个启动脚本，等待 profile directory 变成正确的 symlink 再启动 Firefox：

#!/bin/bash

# Fix "Firefox is already running" at startup when using profile-sync-daemon

set -euo pipefail

while [[ "$(readlink -n ~/.mozilla/firefox/*.default-release)" == /dev/null ]]; do
    sleep 1
done

firefox &

然后根据 Copilot 的建议改成了非轮询，使用 inotifywait（意义不大，主要是学多（

#!/bin/bash

# Fix "Firefox is already running" at startup when using profile-sync-daemon

set -euo pipefail

profile="$(ls -d ~/.mozilla/firefox/*.default-release)"

while [[ "$(readlink -n "$profile")" == /dev/null ]]; do
    inotifywait -P "$profile"
done

firefox &

我是开机时有一个启动脚本启动一堆东西，在那里面调用这个 Firefox 启动脚本。（如果是手动启动可以写个 ~/.local/share/applications/firefox.desktop）

误导性的报错

后来去搜了一下，发现这个误导性的报错历史悠久，20 年前 profile directory 不存在就会报这个：Bugzilla #278860 - confusing "profile in use"/"already running" error when profile is missing (not found)。后来路径不存在的情况修了，但 read-only 等 permission error 还是没修：Bugzilla #381139 - Need different warning for profile RO, in use and missing……。

]]> firefox Arch Linux 问题解决记录 <![CDATA[String.prototype.replace 与隐藏的“$”]]> https://ouuan.moe/post/2023/01/string-prototype-replace https://ouuan.moe/post/2023/01/string-prototype-replace Sun, 29 Jan 2023 12:16:32 GMT tl;dr: replace 的第二个参数应当使用字面量或函数，不应使用带变量的字符串表达式，否则可能发生意想不到的错误替换。

]]> tl;dr: replace 的第二个参数应当使用字面量或函数，不应使用带变量的字符串表达式，否则可能发生意想不到的错误替换。

String.prototype.replace 的第二个参数

(reference: String.prototype.replace() - JavaScript | MDN)

replace(pattern, replacement);

第二个参数 replacement 可以是字符串或函数，如果是函数，则由匹配信息作为参数计算出 replacement，如果是字符串，则可以使用一些 special replacement pattern：

Pattern Inserts
$$ Inserts a "$".
$& Inserts the matched substring.
$` Inserts the portion of the string that precedes the matched substring.
$' Inserts the portion of the string that follows the matched substring.
$n Inserts the nth (1-indexed) capturing group where n is a positive integer less than 100.
$<Name> Inserts the named capturing group where Name is the group name.

使用变量作为 replacement 带来的问题

我实际遇到的问题是 iles#224，由于使用了模板字符串作为 replacement，在变量中包含上面这些 special replacement pattern 时，就会错误地替换。

解决方法也很简单，将含变量的表达式改成函数（前面加上 () => ）就可以了：regex - javascript - Better Way to Escape Dollar Signs in the String Used By String.prototype.replace - Stack Overflow。

因为解决的代价非常小，虽然有的时候根据代码逻辑可以推断出 replacement 不含 $，依然可以认为，凡是 replacement 需要用到变量的，都应当替换成函数。

使用 ESLint 检测这一问题

写了个 no-restricted-syntax 的配置：

{
  rules: {
    'no-restricted-syntax': [
      'error',
      {
        selector: "CallExpression[callee.property.name='replace'] > .arguments:nth-child(2):not(Literal):not(ArrowFunctionExpression):not(FunctionExpression)",
        message: 'Only literals and functions are permitted as the 2nd argument of String.prototype.replace. Use a function that returns the expression instead.',
      },
    ],
  },
}

因为只是分析 AST，有很多情况会误报，例如 replacement 是一个函数名，但实际代码应该很少出现这样的情况，真遇到了的话再套一层函数就 ok 了，实在不行还能用注释 disable 掉 lint。

没研究过，不知道写 ESLint plugin 能不能更加准确地检测，但是差不多得了（

]]> JavaScript 问题解决记录 <![CDATA[探究 gcc 浮点数精度转换所使用的指令 —— use_vector_fp_converts 优化]]> https://ouuan.moe/post/2022/10/gcc-use_vector_fp_converts https://ouuan.moe/post/2022/10/gcc-use_vector_fp_converts Wed, 19 Oct 2022 16:42:57 GMT 在学习 浮点数精度转换指令 时，CS:APP 里提到 gcc 并不使用 vcvtss2sd/vcvtsd2ss，而是使用 vunpcklps & vcvtps2pd / vmovddup & vcvtpd2psx，但是我使用 gcc 12.2.0 编译得到的结果就是 vcvtss2sd/vcvtsd2ss。对此，CS:APP 没有深究：

It is unclear why GCC generates this code. There is neither benefit nor need to have the value duplicated within the XMM register.

但是 CS:APP 选择放弃反而会激发读者的斗志啊（

虽然但是，我确实没想到这玩意会让我断断续续搞了三天，ddl 又要寄了 🌚

]]> 在学习 浮点数精度转换指令 时，CS:APP 里提到 gcc 并不使用 vcvtss2sd/vcvtsd2ss，而是使用 vunpcklps & vcvtps2pd / vmovddup & vcvtpd2psx，但是我使用 gcc 12.2.0 编译得到的结果就是 vcvtss2sd/vcvtsd2ss。对此，CS:APP 没有深究：

It is unclear why GCC generates this code. There is neither benefit nor need to have the value duplicated within the XMM register.

但是 CS:APP 选择放弃反而会激发读者的斗志啊（

虽然但是，我确实没想到这玩意会让我断断续续搞了三天，ddl 又要寄了 🌚

问题描述

这一问题可以由下面的代码所展示：

double f2d(float x)
{
    return x;
}

float d2f(double x)
{
    return x;
}

double fp2d(float *x)
{
    return *x;
}

float dp2f(double *x)
{
    return *x;
}

它编译成汇编的结果有如下几种：

函数 A B A with AVX2 B with AVX2
f2d cvtss2sd unpcklps & cvtps2pd vcvtss2sd vunpcklps & vcvtps2pd
d2f cvtsd2ss unpcklpd & cvtpd2ps vcvtsd2ss vmovddup & vcvtpd2psx
fp2d pxor & cvtss2sd movss & cvtps2pd vxorps & vcvtss2sd vmovss & vcvtps2pd
dp2f pxor & cvtsd2ss movq & cvtpd2ps vxorps & vcvtsd2ss vmovq & vcvtpd2psx

问题在于，gcc 为什么/在什么情况下会生成如 B 所示的指令。其中，使用两条理解起来都不太容易的指令（unpcklps、cvtps2pd）来代替指令集中自带的 cvtss2sd/cvtsd2ss 最令人费解。而 source 为指针的另外两个函数是受 performance - Why don't GCC and Clang use cvtss2sd [memory]? - Stack Overflow 启发。

我先尝试了各种关键词用搜索引擎进行搜索，均未找到答案。

gcc 版本的定位

使用 Compiler Explorer 进行尝试，很快就能确认，是在 gcc 4.8.5 / 4.9.0 之间行为出现了变化。

于是，我先看了 gcc 4.9 changes，又在 commit log 里大力搜索 “cvtss2sd” “cvtsd2ss” “unpcklp” “floating point” “convert”……都没找到相关内容。

具体 commit 的定位：git bisect / 编译 gcc

在各种搜索都失败后，我决定使用 git bisect 找到行为出现变化的 commit。

要 bisect，就得编译 gcc 4.8.5 ~ 4.9.0，步骤大致如下：

  1. 将 gcc 代码 clone 下来: git clone https://github.com/gcc-mirror/gcc --branch releases/gcc-4.9 --depth 50000
  2. 创建 build 目录
  3. 在 build 目录下运行 gcc 仓库根目录的 configure 脚本
  4. 在 build 目录下运行 make

其中，configure 的配置可以参考 Installing GCC: Configuration - GNU Project，但我只是 bisect 一下，就没仔细研究。

过程中走的弯路就不一一细说了，只说一下最终的解决方案中遇到的几个主要问题。

最终的编译命令为:

CC=gcc-4.8
CXX=g++-4.8
make distclean
../gcc/configure --enable-languages=c --disable-multilib --disable-libsanitizer
make -j$(nproc)

语言标准问题

因为编译的是多年前的 gcc 4.8~4.9，用现在的编译器会遇到一些语言标准不同的问题。修改编译选项大概能解决问题，但改起来麻烦，也不见得能解决所有问题，不如直接用旧版 gcc 来编译。

但是现在目标就是编译旧版 gcc，你哪来的旧版 gcc 用来编译？

用旧版 gcc 解决编译旧版 gcc 遇到的问题看起来很矛盾，但我们要解决的是编译两个版本之间的一堆 commit，而获得一个用来编译的旧版 gcc 只需要一个 gcc release 的可执行文件。这个用来编译的旧版 gcc 可以用各种方式下载一个，而我用的是 Arch Linux，就装了 AUR 里的 gcc48。

获得了一个旧版 gcc 后，运行 configure 时修改环境变量 CC 和 CXX 即可使用。

P.S. 我本来想用 AUR 的 PKGBUILD 来编译，但能编译 release 不代表能编译各个 commit，然后踩各种坑踩了半天..

struct ucontext

还会遇到一个编译错误: md-unwind-support.h:65:47: error: dereferencing pointer to incomplete type 'struct ucontext'

将相应代码中的 ucontext 修改为 ucontext_t 即可。

reference: How to compile gcc 6.4.0 with gcc 7.2 in Archlinux - Stack Overflow

libsanitizer

还会遇到一些编译错误，在搜索其中一个的解决方案时，我找到了 一次令人吐血的 ubuntu 源码安装 gcc-5.4.0 经历_亿零贰肆的博客-CSDN 博客_ubuntu 安装 gcc5.4.0。

这篇博客也提到了上面说的 struct ucontext 的问题，而仔细一看就会发现，剩下其他问题全都是 libsanitizer 里的，而我研究这个问题不需要 libsanitizer，直接 --disable-libsanitizer 就能解决这一堆编译错误还能缩短编译用时。

make distclean

修改各种选项或者更换 commit 后，如果直接 make 容易出问题，可以先 make distclean 来重置。

git bisect

在处理完上面几个问题之后，编译就很顺利了。在我 8C16T 的 AMD Ryzen 7 4800H 上，编译一次大约需要 9min。

需要注意的是，因为原问题可以看成是在更老的版本出现，即新版本 good 老版本 bad，但 git bisect 默认是老版本 good 新版本 bad，这里容易搞反，需要注意。（git bisect 可以把 good/bad 改成 old/new，但我懒得（研究怎么）改了。）

bisect 找到的 commit 是 915e8e6e。

从这个 commit 的内容可以得知，那些看起来有些奇怪的编译结果是一个叫做 use_vector_fp_converts 的优化的结果。这个 commit 使得这个优化只对 amdfam10 架构生效，在新版 gcc 中仍可使用 -mtune=amdfam10 选项观察到这一行为（也可以使用 -mtune-ctrl=use_vector_fp_converts 来启用这个优化）。代码中对这一优化给出的理由是 “avoids partial write to the destination”，也就是说 cvtss2sd/cvtsd2ss 只修改目标寄存器的低位，可能导致效率低。

优化最终被关闭的原因

锁定了问题出现的 commit，接下来就是搜索这个 commit 修改的原因了。

在 gcc-patches 里搜索 use_vector_fp_converts，然后再顺着邮件内容找，就可以找到相关邮件：

令我自闭的是..直接搜索 cvtss2sd/cvtsd2ss 就能搜到这些邮件 😵 为什么 bisect 出来才想着在邮件列表里搜呢...（低情商：wssb；高情商：还是 mailing list 使用经验不足 😢）

总结一下这些邮件的内容，就是：

  1. 在一些 Intel CPU 上，某些 test case 上启用 use_vector_fp_converts 更快，另一些 test case 上不启用更快。
  2. 在启用 use_vector_fp_converts 更快的 test case 上，可以通过在 cvtss2sd/cvtsd2ss 之前将 XMM 寄存器清空（pxor %xmm0, %xmm0）以避免只更新低位带来的性能损失，从而达到和启用 use_vector_fp_converts 差不多的性能。所以 157ca3e9 就对 m_CORE_ALL 关闭了这个优化并且在需要时先将 XMM 寄存器清空。
  3. 在 Re: [PATCH] disable use_vector_fp_converts for m_CORE_ALL 中，Honza 表示可以先把上面那个 patch commit 了，他测试一下再决定是否对 m_GENERIC 也关闭这个优化，所以 157ca3e9（对 m_CORE_ALL 关闭优化并在需要时清空 XMM）和 915e8e6e（对 m_GENERIC 关闭优化）分成了两个 commit。

优化最初被添加的原因

继续追根溯源下去，通过 git blame 来找到一开始添加这个优化的原因。

首先找到 54723b46，这个 commit 将 TARGET_USE_VECTOR_FP_CONVERTS 从 TARGET_USE_VECTOR_CONVERTS 中抽离出来成为单独的优化开关。

然后找到 4845dbb5，这个 commit 添加了 X86_USE_VECTOR_CONVERTS，即 X86_TUNE_USE_VECTOR_FP_CONVERTS 的前身。

4845dbb5 的邮件是 SSE conversion optimization，里面写的很简略，就是 “Amdfam10 preffers doing packed conversions destinating SSE register rather than scalar”。

只不过 performance - Why don't GCC and Clang use cvtss2sd [memory]? - Stack Overflow 里还是有一些解释的，反正简单来说就是 partial regisiter update 会有性能损失。

对 m_CORE_ALL、m_GENERIC 启用优化的原因

可以发现，一开始有这个优化时，是只对 m_AMDFAM10 启用的，这和现在是一样的，为什么中间绕了一圈又回到最开始的选择呢？继续寻找对 m_CORE_ALL 和 m_GENERIC 启用这个优化的原因。

首先找到 3ad20bd4，这个 commit 把相关代码挪了个位置。

然后找到 3a579e09，这个 commit 把 m_CORE2I7 改成了 m_CORE_ALL。

然后找到 3a4ffde6，这个 commit 修改了一堆处理器架构的 bitmask，然后..把 m_AMDFAM10 和 m_CORE2I7 换了个位置 🤔

然后找到 ab247762，这个 commit 新增了 m_CORE2I7 架构并且为它启用了 X86_TUNE_USE_VECTOR_FP_CONVERTS。这个 patch 的邮件是 0005-Switch-Core-2-to-new-tuning，给出的原因是 Core 2/i7 比较适合使用 generic tuning，而此时 X86_TUNE_USE_VECTOR_FP_CONVERTS 是对 m_GENERIC 启用的，就也对 m_CORE2I7 启用了。

这时再回头看上面找到的 54723b46，这个 commit 将 TARGET_USE_VECTOR_CONVERTS || TARGET_GENERIC 改成了 TARGET_USE_VECTOR_FP_CONVERTS，所以要 blame 这个 || TARGET_GENERIC。

最后找到是 bf019a1f 添加了 || TARGET_GENERIC。这个 patch 的邮件是 PR target/33396，时间上紧跟着最初的 4845dbb5，而 changelog 和邮件里只提到了添加 TARGET_SSE_MATH 而没有提到添加 TARGET_GENERIC 的原因，并且这封邮件还没人回复。

至此，我已经不知道能如何继续探究下去了。我感觉可能是：

  1. SSE conversion optimization 中提到 “We are now testing if the patch is good for generic”，可能他自己测试之后因为某些原因得到了这个优化 good for generic 的结论，就 commit 了，也没再解释；
  2. 或者是，PR target/33396 里提到了 “failure with 32bit generic”，可能是测试的时候加上了 TARGET_GENERIC，后来忘记删掉了 🤔
  3. 或者是，有什么其他原因，但忘记写在 log / 邮件里了，或者写在某个隐秘的角落我没找到。

反正不管是什么原因，bf019a1f 都是一个 commit 做了两件事，还只写了一件事的 changelog，导致这成了一个谜。

与其他编译器的对比

使用 Compiler Explorer 看一下其他编译器是怎么做的。

clang: 无论是否 -mtune=amdfam10 都没有 use_vector_fp_converts。

MSVC: 无论是否 -mtune=amdfam10 都是 source in register 则 cvtss2sd/cvtsd2ss，source in memory 则表现出 use_vector_fp_converts 的行为。

但是我并不知道如何研究其他编译器为什么做出这样的选择 😢

性能测试

最后来实际测试一下这个优化的性能。

测试使用的代码为 [PATCH] disable use_vector_fp_converts for m_CORE_ALL 中的 1.c 和 2.c，但原来的 2.c 用时太短，所以把循环范围改成了 1ll << 32：

测试使用的编译选项有：

  1. -O2 -mtune-ctrl=^use_vector_fp_converts
  2. -O2 -mtune-ctrl=^use_vector_fp_converts -mavx2
  3. -O2 -mtune-ctrl=use_vector_fp_converts
  4. -O2 -mtune-ctrl=use_vector_fp_converts -mavx2

其中值得注意的是，使用 2 号编译选项编译 2.c 时会通过将 vcvtsd2ss 指令的第二个 operand 设为 %xmm1 来代替 pxor %xmm0, %xmm0 以达到清空 %xmm0 的效果。

为了测试清空 XMM 寄存器的效果，在这 4 种编译选项之外，还对 2.c 增设了手动删掉用于清空 %xmm0 的指令的两份汇编代码。

所以总共有 10 份汇编代码用于测试：

  • 1-1: 1.c，-O2 -mtune-ctrl=^use_vector_fp_converts
  • 1-2: 1.c，-O2 -mtune-ctrl=^use_vector_fp_converts -mavx2
  • 1-3: 1.c，-O2 -mtune-ctrl=use_vector_fp_converts
  • 1-4: 1.c，-O2 -mtune-ctrl=use_vector_fp_converts -mavx2
  • 2-1: 2.c，-O2 -mtune-ctrl=^use_vector_fp_converts
  • 2-2: 2.c，-O2 -mtune-ctrl=^use_vector_fp_converts -mavx2
  • 2-3: 2.c，-O2 -mtune-ctrl=use_vector_fp_converts
  • 2-4: 2.c，-O2 -mtune-ctrl=use_vector_fp_converts -mavx2
  • 2-5: 2.c，-O2 -mtune-ctrl=^use_vector_fp_converts，然后删掉 pxor %xmm0, %xmm0
  • 2-6: 2.c，-O2 -mtune-ctrl=^use_vector_fp_converts -mavx2，然后将 vcvtsd2ss 的第二个 operand 改为 %xmm0。

用于测试的机器有五台，CPU 型号分别为：

  • A: AMD Ryzen 7 4800H with Radeon Graphics （笔记本）
  • B: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz （Hostwinds）
  • C: Intel(R) Xeon(R) CPU E5-4610 v2 @ 2.30GHz （THU 校内服务器）
  • D: Intel(R) Xeon(R) Platinum 8255C CPU @ 2.50GHz （腾讯云）
  • E: Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz （阿里云）

测试时，将程序运行 10 遍，记录其中第 3 短的用时。

测试结果为：

代码/用时(s) A B C D E
1-1 2.10 3.15 3.96 4.62 4.41
1-2 2.10 3.11 3.95 4.61 4.42
1-3 3.50 3.82 4.52 5.30 5.04
1-4 3.50 3.77 4.90 5.30 5.04
2-1 1.62 6.47 7.22 3.59 3.43
2-2 1.41 6.26 7.65 4.31 4.08
2-3 1.61 4.66 5.31 3.24 3.11
2-4 1.61 4.76 5.69 3.59 3.43
2-5 1.40 9.06 10.41 7.12 6.77
2-6 1.41 9.03 10.98 7.11 6.77

这数据真的非常让人怀疑是不是测错了（

只能说是大千世界无奇不有，性能优化实在是太玄学了（

但测试似乎表明，source in register 时关闭 use_vector_fp_converts、source in memory 时开启 use_vector_fp_converts，也就是 MSVC 的选择，在总体上是比较优的。

]]> gcc 性能优化 问题解决记录 <![CDATA[busuanzi 访问量统计与 live2d 插件同时使用导致 busuanzi 不显示的根本原因以及解决方法]]> https://ouuan.moe/post/2022/08/busuanzi-and-live2d https://ouuan.moe/post/2022/08/busuanzi-and-live2d Fri, 05 Aug 2022 05:55:15 GMT 昨天在一位网友的 Hexo 博客遇到了很诡异的 busuanzi 访问量统计不显示问题，经过一番研究发现是 busuanzi 代码的一处问题和 live2d 插件的一处问题凑在一起导致的。

今天在写博客之前先搜了一下 “busuanzi live2d”，发现搜出来一堆结果，我还以为我白研究了..结果点进去一看，第一页结果里没有一个指出了问题的根本原因，而且修复方法基本上都是删 feature 或者换组件，但实际上只要知道问题的根本原因就可以在不妨碍正常功能运作的前提下进行修复。所以昨天晚上没白忙活，我这篇博客还是要写的。

]]> 昨天在一位网友的 Hexo 博客遇到了很诡异的 busuanzi 访问量统计不显示问题，经过一番研究发现是 busuanzi 代码的一处问题和 live2d 插件的一处问题凑在一起导致的。

今天在写博客之前先搜了一下 “busuanzi live2d”，发现搜出来一堆结果，我还以为我白研究了..结果点进去一看，第一页结果里没有一个指出了问题的根本原因，而且修复方法基本上都是删 feature 或者换组件，但实际上只要知道问题的根本原因就可以在不妨碍正常功能运作的前提下进行修复。所以昨天晚上没白忙活，我这篇博客还是要写的。

当然，我只看了第一页搜索结果，可能有更深入研究的文章被搜索引擎埋没了，我这篇文章说不定也不会被搜到，只不过既然第一页没有，就让我也来成为被搜索引擎埋没的一员，这样的话说不定被搜到的可能性就增加了（

问题描述

在一个同时启用了 busuanzi 访问量统计和 live2d 插件的 Hexo 博客里，访问或刷新博客时有大概率 busuanzi 会被隐藏。

被隐藏的具体表现为，刷新的瞬间 id 为 busuanzi_container_* 的容器是显示的，然后容器的样式很快被设为 display: none。

查看 F12 的 Network，busuanzi 相关请求正常返回；console 中没有报错。

问题定位

注：这个过程中我也走了一些弯路，就不写出来了。

设置 display: none 的定位

查看 busuanzi.pure.mini.js，发现 display: none 在 hides 函数中被设置：

hides: function() {
  this.bszs.map(function(a) {
    var b = document.getElementById("busuanzi_container_" + a);
    b && (b.style.display = "none")
  })
},

而 hides 函数仅在一处被调用：

try {
  a(b), scriptTag.parentElement.removeChild(scriptTag)
} catch (c) {
  bszTag.hides()
}

所以是在 a(b), scriptTag.parentElement.removeChild(scriptTag) 抛出异常时容器被隐藏。

异常原因的定位

由于在其它地方的 busuanzi 不会出现这一问题，而问题的原因还完全不清楚，为了尽可能还原原始环境以复现问题，我选择了使用 Firefox 的 Header Editor 插件 直接在原博客进行测试。具体来说，就是在本地复制一份 busuanzi 的代码，然后跑一个 http server，在 Header Editor 里把 busuanzi 代码的请求重定向到本地的 http server。

首先，在 catch 中添加 console.error(c)，得到错误内容 TypeError: scriptTag.parentElement is null。

查看代码中 scriptTag 相关的部分：

scriptTag = document.createElement("SCRIPT"), scriptTag.type = "text/javascript", scriptTag.defer = !0, scriptTag.src = a, scriptTag.referrerPolicy = "no-referrer-when-downgrade", document.getElementsByTagName("HEAD")[0].appendChild(scriptTag)

所以，再在 catch 中添加 s = document.querySelector("[src*=BusuanziCallback]"); console.log(s.parentElement);，发现 s.parentElement 不是 null。

再添加 console.log(s === scriptTag)，发现结果是 s 和 scriptTag 不同，所以原因在于此时的 scriptTag 变量已经不指向 DOM 中的这个元素了。

定位到 live2d 插件

此时我原本是没有任何头绪的，但我发现，并不是每次刷新页面都会触发这一问题，所以没有触发问题时和触发问题时的差别就成了问题的突破口。

经过多次刷新，我发现，有一串 console 输出，在出现问题时总位于我在 catch 中添加的调试信息之前，而在没出现问题时则位于调试信息之后：

Live2D 2.1.00_1 live2d.core.js:5925:16
profile : Desktop live2d.core.js:5913:16
  [PROFILE_NAME] = Desktop live2d.core.js:5918:20
  [USE_ADJUST_TRANSLATION] = false live2d.core.js:5918:20
  [USE_CACHED_POLYGON_IMAGE] = false live2d.core.js:5918:20
  [EXPAND_W] = 2

多亏了 live2d 的这串输出，我得以将问题定位到 live2d 插件上。

实际上，如果没有这些 console 输出，也可以通过 <head> 中 L2Dwidget.0.min.js 和 busuanzi?jsonpCallback=BusuanziCallback 两个 <script> 的相对位置发现问题，只不过这样的话就更隐蔽更难发现了。

在 live2d 插件中定位问题

在 L2Dwidget.min.js 的第一行有源码地址以及时间：/*! https://github.com/xiazeyu/live2d-widget.js built@2019-4-6 09:38:17 */

因为注释中给出的时间不是最新版本，先查看 git log 并 checkout 到相应时间的版本。

既然问题在于 <script> 元素被重新创建而导致原变量不指向 DOM 中元素，就在代码中 grep head，然后发现 问题代码：document.head.innerHTML += ……

至此，问题原因已发现，就是 live2d 插件通过修改 document.head.innerHTML 来添加样式，导致 busuanzi 的 scriptTag 变量指向的不再是 DOM 中的 <script> 元素。

实际上，live2d 插件的这一问题 已经修复，但需要使用新版才行。

解决方法

修改 busuanzi 的解决方法

因为 busuanzi 的代码较短，而且本来就是用的外部的代码，改起来比较容易。

把 scriptTag.parentElement.removeChild(scriptTag) 修改为 s=document.querySelector('[src*=BusuanziCallback]'),s.parentElement.removeChild(s) 即可。可以把修改后的静态文件放在博客里，然后修改 busuanzi <script> 的 src。

网上搜到的很多解决办法是把 id="busuanzi_container_*" 删掉，这样当然就不会被隐藏了，只不过这个隐藏本意是在出错时不把错误或者无意义的内容显示给访客，保留这一行为还是挺好的。

修改 live2d 的解决方法

总之，就是把 innerHTML += 换成 createElement 和 appendChild，按 xiazeyu/live2d-widget.js#61 改就行。

live2d 的代码还是挺长的，直接修改 minify 后的代码不太好。如果是 hexo 插件的话，要修改应该也蛮麻烦的。总之，如果你知道怎么改比较好的话可以改，不然的话还是推荐改 busuanzi。

问题启示

不要修改原 DOM 中的 innerHTML

直接修改 DOM 元素的 innerHTML 会让其中的元素都重新渲染（加载？创建？），不仅指向其中元素的变量会失效，也可能导致画面闪烁等问题（例如导致 live2d-widget 修复这一问题的不是 busuanzi 失效而是 CSS 闪烁）。

所以，如果是添加 DOM 元素，应当避免修改 innerHTML，而应当使用 document.createElement 和 Node.appendChild() 以及 removeChild、replaceChild、insertBefore 等 API。

不要依赖于指向 DOM 元素的变量长时间不改变

如果 DOM 因各种原因部分重建，指向 DOM 元素的变量很可能不再指向当前 DOM 中的元素。所以，最好不要在过了一段时间后（例如在 callback 中）再次使用指向 DOM 元素的变量，而应当再次获取这一元素。

不要 silently fail

在处理异常，尤其是未知的异常时，即使不 throw 出去，也最好用 console.error 等方法记录下来。记录在 console 中的错误信息并不会显示给普通用户，但可以给寻找问题所在的用户提供宝贵的提示信息。

使用 Header Editor 在对原环境最小修改的情况下进行调试

这次使用 Header Editor 调试还是我临时想到的（知道有这么个插件还是以前用 mahjong-helper，当然现在已经没在用了）。一开始还用 pastebin 上传代码，效率极低，后来才想起来本地跑个 http server 就可以了..用这个插件来调试还是挺方便的。

留心依赖版本

一开始我还在 GitHub 上搜到一个 busuanzi.pure.js，调了一会儿才发现这个代码和 https://busuanzi.ibruce.info/busuanzi/2.3/busuanzi.pure.mini.js 不一样..

live2d 的版本也要注意开头包含时间的注释，因为最新版本已经把问题修复了。

]]> busuanzi live2d JavaScript Web 问题解决记录