手元では再現しないが厄介なバグを割り振られ、ここ一週間くらいじっとログやコードを睨んでみたり再現を試みたりしていたがあまり打ち手がなく、仕方ないので問題が起きた時にそれを検知してこっそりアプリを殺す、という回避策コードをコードレビューにだしたところ「これほんとに治るの？それとも speculative fix なの？」というので「speculative だし fix ですらない partial mitigation ですよたぶん dead lock かなんかっぽいんだけど・・・」と返事。すると「Dead lock なら再現したときに bugreport とると thread dump が入るからわかるよ」と指摘される。なんだって！Bugreport なら最初にもらったやつが一個だけあるよ！さっそくログをにらみ直すとたしかに最後の方に thread dump が。そしてたしかに dead lock (じゃないんだけど似たような事態) がおきている！

普段はそのへんのノイズをフィルタし表示してくれるビューアを使っていたのでまったく気づいてなかった。この一週間はなんだったのか・・・といっても dead lock ぽいなと気づいたのは数日前。この数日はなんだったのか・・・。

適当な修正を書き、問題の箇所の持ち主にレビューを出す。そしてあちこちたらい回された結果、どうもその問題はちょっと前に依存関係の奥の方で修正されていたとわかる。そりゃ再現しないわけだわ・・・。

というわけで自分の書いたコードたちはチェックインされることなくバグがなくなり、めでたく締め切り前のノルマ完了。まあそれらのコードは会話のきっかけみたいなもんだったのでどうでもいいんだけど、ストレスがしんどい一週間だった・・・。

Bugreport に thread dump が入っているのを知らなかったのは残念だったが、それ以前に自分はほんとにログを読むのが下手だなあと思う。あとからみると、たしかに根本にあった問題を匂わせる出力はログに含まれていた。しかしノイズをかき分けてそれに気づくだけの才覚がなかった。

しょうじきこの「Bugreport のログから色々読み取る」というスキルはレガシーかつドメイン固有な上に持つと色々嫌なものを引き寄せてしまう気がするのであまり上達したいとも思わないのだが、一方で性能改善の仕事をしているとログを相手にトラブルシュートしなければいけないことは多い。生き延びるためにある程度は鍛えないといけないのだろうなあ。やだやだ・・・。

この「手元では再現しないがおかしい」という類のバグは、特に性能がらみでよくおこる（「なんか遅かった」的なやつ。) On-device tracing があるとだいぶ違うが大抵 trace なんてとってくれないので bugreport の限られた情報から憶測するしかない。多くの場合はしばらく睨んだ末に「わからん。降参」となって終わり。この triage 作業は今の仕事で一番イヤな部分と言えよう。やりたくないけど、性能仕事をしている限りは逃げられない。厳しい。色々対策は考えてるけど、どうなるかね。