php-srcにバグ報告をしてみよう - でかいソフトウェアのバグを見つけよう -

php-srcのバグを見つけてみませんか？
とはいえ、大規模なオープンソースソフトウェアのバグを見つけるときに、切り出すのがすごく難しいので、ノウハウを共有してみたいです。

PHPカンファレンス2021
https://phpcon.php.gr.jp/2021/

Transcript

1. php-srcのバグを見つけよう
2. 自己紹介 てきめん • https://tekitoh-memdhoi.info • @youkidearitai • https://www.youtube.com/user/tekitohmrp php-srcでバグ2個見つけました • https://bugs.php.net/bug.php?id=77165 • https://bugs.php.net/bug.php?id=80771 オンラインでしかできないことだと思うのでこの姿でやります
3. OSSのバグを見つけよう オープンソースソフトウェアの バグを見つけよう
4. なぜ見つけるのか • 巨大なOSSは見つかっていないバグがある • 巨大であるにもかかわらず、大規模にコードが変更される • 貢献することで世界を変えられる • 変な変更を監視する必要がある • 自分の指摘したバグが治ってるのを仕事で使うと気持ちがい い – 最近だとDocker使うことがあるからね
5. 見つけるのは難しい 1 • 内部構造に詳しくないとわからない？ – その内部を作った人よりも詳しい人っている？ – C言語読める必要ある？ • php-srcは「php-srcにカスタマイズされたマルチプラット フォームのC言語フレームワーク」ともとれ、独特なコードもあ るわけで
6. 見つけるのは難しい 2 • 巨大なOSSは見つかっていないバグがあるが – 巨大すぎる！！ • 総ステップ数でいうと1200000くらい(PHP 8時点)あるよね • どうバグを見つければいいんだ…と立ち尽くすしかない 何かしらのアプローチを変える必要がありそうだ
7. 見つけるのは難しい 3 • 巨大であるにもかかわらず、大規模にコードが変更される – Zend Engineもがらりと変わるし • extension書いてると、Cの関数削除されててバージョン移したら動かな いじゃん！？とかなる – extensionもがらりと変わるし • 特にmbstringとかすごい変わる(major overhaul of mbstringとか) • 他にもたくさんあると思う（理解しきれない） ユーザーランドでは後方互換性はあるけどinternalsは違う
8. 見つけるのは難しい 4 • 巨大であるにもかかわらず、歴史が非常に長い – 5.0は2004年リリース – 4.3は2002年リリース • 歴史が長く、資料を集めるのが大変 – この挙動はなぜこうなっている？ 歴史の厚みが複雑さを増して襲いかかる
9. 見つけるのは難しい 5 • バグをバグと定義するのが難しい – マニュアルや仕様にない挙動をどうするのか？ – is_float(-9223372036854775808);がtrueになるのはなぜ？ • これはバグじゃない（えーっ！？）（”-”と”9223372036854775808”が分割された トークンとして解釈される仕様のため） • もちろん、こういうのをbugs.php.netに残してくれると助かる、本当のバグは bugs.php.netで見つからないから – 貴重な例： https://bugs.php.net/bug.php?id=78081 – ※RFCによる同意が得られればこちらが仕様になるかもしれない： https://github.com/php/php-src/pull/6147 明らかなsegfaultなどを除いて間違っていると言えるか？
10. バグかな？と思ったら 1 • バグを起こす最小のコードを調べる • 同じようなバグが報告されているか調べる • メーリングリストとかで言及されてないか調 べる • $ git blame # は貴重なリーフ、たどっていく
11. バグかな？と思ったら 2 • Twitter等、SNSで騒いでみる –誰かが何か指摘してくれたら自分の勘違いの可能 性が高い • （私が間違っているだけだ、助かる） –誰も指摘しなかったらバグかもしれないと感じだす • （ヤバい、世界が間違っているかもしれない）
12. 私が間違っているだけで、PHPが間 違っていないなら私が恥をかくだけ。 ヤバいのはPHPがバグっていること。 世界が間違っているから
13. バグを探すのであれば「自分が 間違っている、世界が正しい」と 思って探してる
14. 巨大なソフトウェアのバグをど うやって見つけ出すか
15. 内部構造を知るべきか？ • 内部構造を知らないと出来ないか –知ってるとよいが、ユーザーランド でわかるし、全てを理解しなくてよ い
16. 何を知らないといけないか • 特徴がわかれば良いのでは • それが固まりとなると集合知になる し、歴史になる • 特徴が変化するときにあれ？となる
17. 特徴を理解する • ここで言う特徴とは –「知ってる」っていう部分 –特徴を集めていく –特徴から挙動を理解していく • 何が入力されたら何が出力されるかとか あなたの興味のある部分を調べて特徴にしていこう
18. 知ってた特徴から見つけたバグ • 例：mbstring関数の特徴 –PHP 7.0まで、引数にstringを要求されて るのにarrayを入れるとmbstringだけ falseが返ってくる（他の関数はnullが多 かった)
19. 知ってた特徴から見つけたバグ • 例：mb_check_encoding(array()); <= 7.0 7.1 7.2 => FALSE NULL TRUE
20. 知ってた特徴から見つけたバグ • 例：mb_check_encoding(array()); • 7.3.0RC5でcrashしたので報告した • https://bugs.php.net/bug.php?id=771 65
21. 知ってた特徴から見つけたバグ 特徴を理解し、挙動から調べる いつでもおかしい挙動をバージョ ンが繰り上がるごとに調べていく
22. 特徴の理解の仕方 1 • 特徴を理解する方法として –ソース読む –PHP Internalsのメーリングリストを読んでる –GitHubのPull Requestを購読してる –他にもgit pull してきてコンパイルを毎日やるとかがあ るっぽい ソースコードの変化を調べる
23. 特徴の理解の仕方 2 • 特徴を理解する方法として写経がある –ソースコードの写経をしている、したリスト • var_dump –zval構造体の理解に役に立った • debug_print_backtrace –バックトレースの理解に役に立った • phpinfo –MINFOなど、設定方法などがわかった php-srcがわからないならphp-srcを写経すれば良い
24. 写経して知る特徴 • phpinfoを写経すると、知らない特徴がたくさん出てくる –Windowsでの挙動 • Architectureという欄が追加されてる • Compilerという欄が追加されてる –イースターエッグ マニュアルにない挙動がたくさんある
25. 写経して知る特徴とバグ • phpinfoを写経すると、知らない特徴がたくさん出てくる –ソースコードから、phpinfo(INFO_CREDITS);をCLIで実行 すると表示されないことに気がついたので報告した –https://bugs.php.net/bug.php?id=80771
26. 見つけたバグとの葛藤 • phpinfoにバグがあるなんて誰も知らなかったらしく、遡ること 18年くらい前から残ってたバグだった • そのため、報告する私も「これバグなのか？」ってなった • このときに「自分が間違っている」と思っているので、「PHP が間違ってるわけ無いだろ」と無視する可能性もあった – 傍観者効果に陥りそうだった、打ち消す必要がある 誰も！！バグ報告していないのである！！とはなりたくない
27. 私は間違っているとは bugs.php.netで報告するとき悩む… • 「それはバグではない」ことがわかったこと • これを打ち消すときは「それがバグである」ことを意味する • しかし、現実には「バグではない証拠を見つけられなかった」 となる –無いとは言えない、知らないだけかもしれないから –だから、間違っているとする根拠はソースコードのみ
28. バグ 私は間違っている VS 歴史 コードの 間違い オレは 間違っている 18年 潜んでいた バグ phpcredits()は 正常に動いてる マニュアルは phpcredits()を 参照しろとある PHPが 間違っている はずがない 仮にバグだった として、 後方互換性は？ どこかに 仕様である 証拠はない？
29. 最後はもう勢い 結局悩んでても仕方がない、私 はこう思うというのをExpected に書いてSubmitだ
30. バグを指摘した後の影響？ 1 • 長きにわたるバグを見つけ出して報告したらどうなるのか – （たまたまなのかわかりませんが）連鎖的に見つかります • https://bugs.php.net/bug.php?id=80915 • https://bugs.php.net/bug.php?id=81048 Bug #80915 $foo =& $_SERVER; \phpinfo(INFO_VARIABLES); // $_SERVERがなくなる print_r($_SERVER); Bug #81048 array_walk($_SERVER, function($value, $key) { }); // Array to string conversionが出る phpinfo(INFO_VARIABLES);
31. バグを指摘した後の影響？ 2 • PHPerKaigiでイースターエッグの話をしたので、イースターエッグの修正も 入りました（ChangeLogには載ってない、イースターエッグっぽくてよき） – 来年の4/1にもphpinfo()を各バージョン見くらべようね！ – elePHPantの文化に詳しくなかったから指摘してくれて嬉しい • 興味あったらさがしてみてね 確かに他にもあるんじゃねって見つけたくなるよね
32. 面白いと思ったバグを見つけたら • そこにヒントがあるかもしれない – あれ？って思ったバグを調べてみよう • 再現したりして「そしたらこれはどうかな？」ってやってみるとか • 1個見つかれば多分何個か出てくると思う！ • 他の人が見つけても、それが学びになるから追いかけると詳し くなれる！ バグを皮切りに色々動くかも！！
33. Fix Typoという貢献 • バグの一つに、ソースコードに変数名やコメントにtypoがある – 「Fix typo」のようなtypoを修正するPull Requestはよくある – ソースコードを目を皿のように読まないとわからない • 修正する側もすごいし、受け入れてる側もすごい – 変数名、コメント程度で挙動に影響しないものは、CIをスキップ できるので、「[skip-ci] Fix typo」のようなコミットが多かった typoの修正も貴重な貢献の一つです！
34. 変な変更を監視する必要とは • 2021年3月末、バックドアが仕掛けられる事件があった – [skip-ci] Fix typoでCIをスキップでき、たくさんあったFix typoの一つと して紛れ込ませた – つまり、「Fix typo」の貢献を悪用しながら、CIと人間の目をかいくぐり、 バックドアを仕掛けようとしたという巧妙なもの • masterへのコミットなので、実被害はphp-srcを開発してる、とか じゃないとないでしょう。 • 自分が気がついたときは「Revert: Revert: Revert... 」のよう に、Revertが繰り返されたPull Requestがあったとき
35. この事件の影響 • PHP 7.4.17 と 8.0.4 がスキップされる(欠番になる) – RC1が出てから2週間のうちにリリースとなるのが通常 • この事件の検証をしてて4週間分の修正を反映とするのは厳しかったため – 私のみつけたphpinfoのバグ（#80771)がスキップされた(´・ω・｀) • git.php.netが閉鎖され、GitHubのほうを使うようになった • かなりたくさんあったFix typoが少なくなった（と思う） – 実は、同時期に機械的に見つける手法で大量のtypoを修正するPull Request も一因（今コレをやるべきじゃないと思うけど（拙訳）ってあるけどありがたい） • https://github.com/php/php-src/pull/6822
36. まとめ • バグは明後日の方向からやって来ることもあるけど… • まず、注目しているソフトウェアの一部分の挙動を理解すること。数百万のコー ドなんて考えなくていい。興味ある部分を調べてみよう • 一つの挙動を完璧に理解しよう。それの変化を見たらバグがないか調べよう • 結局は勢いだし、報告してくれてバグでなかったとしても助かる みんなでバグを報告していこう
37. バグ報告はいいぞ
38. • 2019年5月ごろに3D化しました。 • コロナ禍でオンラインカンファレンスが中心になっ て、オンラインでしかできないことをやりたいと思って この姿で登壇してます。 この3Dアバターについて • MagicaVoxelとBlenderを使ってます！今なら色々なプラットフォームがあって3Dアバターを 作りやすいと思います。 • 3Dアバターで登壇するメリットはこういうのがあります – 顔を見せる必要がない – 自分というキャラクターを出せる、好きになれる – 身振り手振りなどの応用も効かせられる(表示は3tene、手はLeap Motion使ってます)
39. おしまい ご清聴ありがとうございました 参考になれば幸いです。 高評価、チャンネル登録、ツイッターのフォローお願いします