博士

ロボ子、Google Docsで致命的なバグが発生したらしいのじゃ。

ロボ子

それは大変ですね、博士。ユーザーが編集できなくなるなんて、一体何が原因だったんでしょう？

博士

原因が特定バージョンのChromeのみで発生する問題だったのが厄介だったみたいじゃ。しかも、Google Docsのリリースとは関係なかったらしいぞ。

ロボ子

ログを調査しても影響を受けた内部ユーザーが見つからなかったとのことですが、どのようにして問題を特定したんですか？

博士

スクリプトツールを使って、50ページのドキュメントでテキストの太字化と解除を繰り返すテストをしたらしいのじゃ。すると、20回目くらいでクラッシュしたみたいだぞ。

ロボ子

なるほど、再現テストでようやくエラーが確認できたんですね。太字テキストが非太字テキストよりも幅が広いことが関係しているというのは、面白い発見です。

博士

そうじゃ。Google Docsはすべての要素を絶対位置で配置するレイアウトエンジンを使っているから、ビュー内のすべてのものがキャッシュされていて、それが悪さしたみたいじゃな。

ロボ子

ビューの不適切なブックキーピングが原因で、ガベージキャッシュ値を読み取って操作しようとした結果、クラッシュが発生したんですね。

博士

問題は非決定論的で再現に時間がかかったみたいじゃ。原因の特定に2日間もかかったらしいぞ。

ロボ子

Math.abs()関数が負の入力に対して負の値を返すという現象は、一体どういうことですか？

博士

ChromeのV8エンジンにバグがあったらしいのじゃ。最適化パスのリファクタリング時に、Math.abs()を恒等関数にしてしまったらしいぞ。

ロボ子

スーパー最適化レベルでMath.abs()を恒等関数にしてしまったとは、信じられません。一時的な対応として、特定のChromeバージョンに対して手動でif文を実行するブラウザチェックを追加したんですね。

博士

こういうバグは本当に怖いぞ。まさかMath.abs()が原因だったとは誰も思わないからのじゃ。

ロボ子

本当にそうですね。今回の件で、最適化されたコードの隅々まで注意を払う必要があることを改めて認識しました。

博士

ロボ子も気をつけるのじゃぞ！…って、ロボ子にバグがあったら、それはそれで面白いかも…って、冗談じゃ！