Google Docs 裡 Grammar Correction 的 bug

剛剛在 Hacker News 上看到有趣的 bug,在 Google Docs 上輸入 And. And. And. And. And. 會觸發 error:「Including “And. And. And. And. And.” in a Google doc causes it to crash (」,原始的 bug report 在「Including "And. And. And. And. And." in a Google doc causes it to crash.」這邊,錯誤訊息像是這樣:

Hacker News 上的討論有提到這需要開 grammar check 的功能,然後看起來只要有相同的五個字開頭都大寫就會發生,像是 Also, Therefore, And, Anyway, But, Who, Why. 這些:

Also, Therefore, And, Anyway, But, Who, Why.

Each in caps 5 times with the same word with a period and space after each word and newline at the end is what I have found so far.

Can anyone find others?

Edit: added words that work found in other comments

很有趣的 bug XDDD 然後目前在 Hacker News 首頁的第一名...

Kagi 的宗教戰爭:Emacs 與 Vi

目前都是用 Kagi 當作預設的搜尋引擎,然後 Kagi 習慣每個禮拜會給一個 Changelog... 而這個禮拜的 Changelog 是這樣:


Searching for emacs redirects to vi #327 @yjp20

然後 bug report 裡面提到了他會在搜尋 Emacs 時提示 Vi

然後搜尋 Vi 時提示 Emacs:

這是想要掀起什麼宗教戰爭嗎 XDDD

最近 Linux 核心安全性問題的 Dirty Pipe 故事很有趣...

Hacker News 上看到「The Dirty Pipe Vulnerability」這個 Linux kernel 的安全性問題,Hacker News 上相關的討論在「The Dirty Pipe Vulnerability (」這邊可以看到。

這次出包的是 splice() 的問題,先講他寫出可重製 bug 的程式碼,首先是第一個程式用 user1 放著跑:

#include <unistd.h>
int main(int argc, char **argv) {
  for (;;) write(1, "AAAAA", 5);
// ./writer >foo

然後第二個程式也放著跑 (可以是不同的 user2,完全無法碰到 user1 的權限):

#define _GNU_SOURCE
#include <unistd.h>
#include <fcntl.h>
int main(int argc, char **argv) {
  for (;;) {
    splice(0, 0, 1, 0, 2, 0);
    write(1, "BBBBB", 5);
// ./splicer <foo |cat >/dev/null

理論上不會在 foo 裡面看到任何 BBBBB 的字串,但卻打穿了... 透過 git bisect 的檢查,他也確認了是在「pipe: merge anon_pipe_buf*_ops」這個 commit 時出的問題。

不過找到問題的過程拉的頗長,一開始是有 web hosting 服務的 support ticket 說 access log 下載下來發現爛掉了,無法解壓縮:

It all started a year ago with a support ticket about corrupt files. A customer complained that the access logs they downloaded could not be decompressed. And indeed, there was a corrupt log file on one of the log servers; it could be decompressed, but gzip reported a CRC error.


I fixed the file’s CRC manually, closed the ticket, and soon forgot about the problem.

接下來過幾個月後又發生,經過幾次的 support ticket 後他手上就有一些「資料」可以看:

Months later, this happened again and yet again. Every time, the file’s contents looked correct, only the CRC at the end of the file was wrong. Now, with several corrupt files, I was able to dig deeper and found a surprising kind of corruption. A pattern emerged.


None of this made sense, but new support tickets kept coming in (at a very slow rate). There was some systematic problem, but I just couldn’t get a grip on it. That gave me a lot of frustration, but I was busy with other tasks, and I kept pushing this file corruption problem to the back of my queue.

後來真的花時間下去找,利用先前的 pattern 掃了一次系統 log,發現有規律在:

External pressure brought this problem back into my consciousness. I scanned the whole hard disk for corrupt files (which took two days), hoping for more patterns to emerge. And indeed, there was a pattern:

  • there were 37 corrupt files within the past 3 months
  • they occurred on 22 unique days
  • 18 of those days have 1 corruption
  • 1 day has 2 corruptions (2021-11-21)
  • 1 day has 7 corruptions (2021-11-30)
  • 1 day has 6 corruptions (2021-12-31)
  • 1 day has 4 corruptions (2022-01-31)

The last day of each month is clearly the one which most corruptions occur.

然後就試著寫各種 reproducible code,最後成功的版本就是開頭提到的,然後他發現這個漏洞可以是 security vulnerability,就回報出去了,可以看到前後從第一次的 support ticket 到最後解決花了快一年的時間,不過 Linux kernel 端修正的速度蠻快的:

  • 2021-04-29: first support ticket about file corruption
  • 2022-02-19: file corruption problem identified as Linux kernel bug, which turned out to be an exploitable vulnerability
  • 2022-02-20: bug report, exploit and patch sent to the Linux kernel security team
  • 2022-02-21: bug reproduced on Google Pixel 6; bug report sent to the Android Security Team
  • 2022-02-21: patch sent to LKML (without vulnerability details) as suggested by Linus Torvalds, Willy Tarreau and Al Viro
  • 2022-02-23: Linux stable releases with my bug fix (5.16.11, 5.15.25, 5.10.102)
  • 2022-02-24: Google merges my bug fix into the Android kernel
  • 2022-02-28: notified the linux-distros mailing list
  • 2022-03-07: public disclosure

整個故事還蠻精彩的 XD

Mac 上 sprintf 的 scalability 問題

Hacker News 上看到個有趣的 scalability 問題,在 Mac 上的 sprintf() 因為有 lock 造成的 scalability 問題:「Curious lack of sprintf scaling (」。

作者注意到 Mac 在多 CPU 下 sprintf() 會有 scalability 的問題,要注意到這邊的 Y 軸是對數比例:

用了 std::stringstream << 反而更慢 (作者還酸了一句「Zero cost abstractions」):

然後用了 Instruments 跑 profiling 找問題,可以看到看起來跟 locale 有關:

一般的情況下應該不會是問題,但如果是需要大量 sprintf() 組字串的人就會比較要注意了。

在「What else can we do?」這段有提到一些解法,包括了 stb_sprintf 當作替代品,以及 {fmt} 作為 iostreams 的替代品,然後另外是利用 to_chars 來解決,如果只是要把數字轉成字串。

算是蠻有趣的 bug hunting 過程,對於開發者來說,一般性的重點還是在 profiling,找到對的問題然後再往下提出解法...

Mutt 現有維護者的節能宣告

Hacker News 上看到「Mutt 2.2.0 (」這篇,Mutt 的維護者 (應該是 Kevin McCarthy) 將只會負責 fix 類的事情了:

This obviously isn't a feature, but I wanted to mention that I will be moving away from Mutt maintainership after this release. There isn't a transition plan, so I'll keep maintaining the 2.2.x series with bug fixes and security issues.

It's been my pleasure to keep the releases coming since version 1.5.24. Unfortunately the past year, my time and energy available has been decreasing. So my plan is to focus the time I do have on keeping Mutt stable, secure, and bug free; until someone else has the desire to head up (and support) new-feature releases. Thank you everyone!

有人在討論串裡提到了 NeoMutt,也許之後會找機會看看...

目前還是有一套 email system 是跑在 Postfix + Procmail + Bogofilter + Mutt 上面,短期內應該不會換...

Apple 對 PNG 解碼的 bug

前幾天的 Hacker News Daily 上看到「PNG Parser Differential」這個,對應的討論在「PNG Parser Differential (」這邊可以看到。

作者想要利用 threading 加速處理 PNG 格式,結果寫出了 bug,但意外發現 Apple 的 PNG decoder 也犯了一樣的問題:「Ambiguous Decodes #3」。

作者做了一個特別的 PNG 放在網站上,在非 Safari 的情況下會是:

而拿 iPhone 的 Safari 讀的話,可以看到:

應該是 implementation bug,還蠻有趣的 bug...

XFCE 配上 Chromium 系列瀏覽器 (Chrome/Brave/...),視窗最大化時的問題

今天發現 Brave 在視窗最大化時會超出預期的邊界,而非放大到螢幕的邊緣,找了一下發現有人已經在 Brave 的 GitHub 上開了「Incorrect scale if browser is full screen #18964」這張票,後來看到有人說在 Chromium 的 bug system 上已經有人提出來了:「Issue 1257119: Goes under the taskbar when maximized」、「Issue 1260821: maximise gets screen dimension wron」與「Issue 1261797: [User Feedback - Stable] Reports that when Chrome is maximized after being minimized, it launches to beyond the window frame on Linux」。

這次遇到的 bug 看起來是只有用 XFCE 的使用者才會中獎,目前先摸索出一套 workaround 是透過 wmctrl 操作修改瀏覽器的位置與視窗大小。

方法是先用 wmctrl -l -G 列出所有視窗的資訊,包括 geometry 的資料,接著再用 wmctrl -i -r 0x12345678 -e 0,3760,15,1232,1935 這樣的指令去指定瀏覽器的位置與視窗大小。


獨立遊戲創作者推出 Linux 版的好處


Hacker News 首頁上翻到的,以這個 upvote 數量來看,應該會收到今天的 Hacker News Daily 上:「Despite having just 5.8% sales, over 38% of bug reports come from Linux (」。

作者是一位獨立遊戲開發者,在兩年前推出了「ΔV: Rings of Saturn」這款遊戲,並且也發佈了 Linux 版。

作者先就數字來比較,他賣出了 12000 套,其中 700 套是 Linux 玩家;另外他收到了 1040 個 bug report,其中大約 400 個是從 Linux 玩家回報的:

As of today, I sold a little over 12,000 units of ΔV in total. 700 of these units were bought by Linux players. That’s 5.8%. I got 1040 bug reports in total, out of which roughly 400 are made by Linux players.

That’s one report per 11.5 users on average, and one report per 1.75 Linux players. That’s right, an average Linux player will get you 650% more bug reports.

看文章時可能會覺得「Linux 玩家真難伺候」,但實際上作者講到,這 400 個 bug 裡面只有 3 個 bug 是平台相關的 (只會發生在 Linux 上),其他的 bug 其實是所有平台都會發生:

A lot of extra work for just 5.8% of extra units, right?

Wrong. Bugs exist whenever you know about them, or not.

Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone[.]

原因是 Linux 社群在參與各種 open source project 養成的習慣,會盡可能把各種資訊講清楚,並且找出可以重製問題的方式:

The thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!

But that’s not all. The report quality is stellar.

與一般玩家的回報方式完全不同,Linux 玩家很習慣就會附上基本的環境資訊,系統紀錄,甚至有時候還會包括 core dump 與 reproducible steps:

I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed.

And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.

不知道有沒有遇到回報 GDB 資訊的...

很特別的分享 XDDD

EULA 不能禁止使用者 decompile 修 bug

Hacker News Daily 上翻到的,歐洲法院認為 EULA 不能禁止使用者 decompile 修 bug:「EU court rules no EULA can forbid decompilation, if you want to fix a bug (」,官方的英文版文件在這邊可以翻到,不過原始判決是法文:

* Language of the case: French.

這是 Top System SA 與比利時政府打的訴訟,法院認為修 bug 而需要 decompile 這件事情是合法的,即使考慮到 Article 6 的規範:

In the light of the foregoing considerations, the answer to the first question referred is that Article 5(1) of Directive 91/250 must be interpreted as meaning that the lawful purchaser of a computer program is entitled to decompile all or part of that program in order to correct errors affecting its operation, including where the correction consists in disabling a function that is affecting the proper operation of the application of which that program forms a part.

In the light of the foregoing considerations, the answer to the second question referred is that Article 5(1) of Directive 91/250 must be interpreted as meaning that the lawful purchaser of a computer program who wishes to decompile that program in order to correct errors affecting the operation thereof is not required to satisfy the requirements laid down in Article 6 of that directive. However, that purchaser is entitled to carry out such a decompilation only to the extent necessary to effect that correction and in compliance, where appropriate, with the conditions laid down in the contract with the holder of the copyright in that program.


REQUEST for a preliminary ruling under Article 267 TFEU from the Cour d’appel de Bruxelles (Court of Appeal, Brussels, Belgium), made by decision of 20 December 2019, received at the Court on 14 January 2020[.]

但不管怎樣,算是有些東西出來了... 然後 Hacker News 上面的討論就看到一些很歡樂的例子:

This becomes incredibly interesting in terms of e.g. Denuvo. This anti-piracy middleware has been shown to make games unplayable, and this EU law seems to support removing it.

哭啊怎麼提到該死的 Denuvo XDDD