Tweet
Tweet

Slide 1

Slide 1 text

php-srcのバグを見つけよう

Slide 2

Slide 2 text

自己紹介 てきめん ● 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 オンラインでしかできないことだと思うのでこの姿でやります

Slide 3

Slide 3 text

OSSのバグを見つけよう オープンソースソフトウェアの バグを見つけよう

Slide 4

Slide 4 text

なぜ見つけるのか ● 巨大なOSSは見つかっていないバグがある ● 巨大であるにもかかわらず、大規模にコードが変更される ● 貢献することで世界を変えられる ● 変な変更を監視する必要がある ● 自分の指摘したバグが治ってるのを仕事で使うと気持ちがい い – 最近だとDocker使うことがあるからね

Slide 5

Slide 5 text

見つけるのは難しい 1 ● 内部構造に詳しくないとわからない？ – その内部を作った人よりも詳しい人っている？ – C言語読める必要ある？ ● php-srcは「php-srcにカスタマイズされたマルチプラット フォームのC言語フレームワーク」ともとれ、独特なコードもあ るわけで

Slide 6

Slide 6 text

見つけるのは難しい 2 ● 巨大なOSSは見つかっていないバグがあるが – 巨大すぎる！！ ● 総ステップ数でいうと1200000くらい(PHP 8時点)あるよね ● どうバグを見つければいいんだ…と立ち尽くすしかない 何かしらのアプローチを変える必要がありそうだ

Slide 7

Slide 7 text

見つけるのは難しい 3 ● 巨大であるにもかかわらず、大規模にコードが変更される – Zend Engineもがらりと変わるし ● extension書いてると、Cの関数削除されててバージョン移したら動かな いじゃん！？とかなる – extensionもがらりと変わるし ● 特にmbstringとかすごい変わる(major overhaul of mbstringとか) ● 他にもたくさんあると思う（理解しきれない） ユーザーランドでは後方互換性はあるけどinternalsは違う

Slide 8

Slide 8 text

見つけるのは難しい 4 ● 巨大であるにもかかわらず、歴史が非常に長い – 5.0は2004年リリース – 4.3は2002年リリース ● 歴史が長く、資料を集めるのが大変 – この挙動はなぜこうなっている？ 歴史の厚みが複雑さを増して襲いかかる

Slide 9

Slide 9 text

見つけるのは難しい 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などを除いて間違っていると言えるか？

Slide 10

Slide 10 text

バグかな？と思ったら 1 ● バグを起こす最小のコードを調べる ● 同じようなバグが報告されているか調べる ● メーリングリストとかで言及されてないか調 べる ● $ git blame # は貴重なリーフ、たどっていく

Slide 11

Slide 11 text

バグかな？と思ったら 2 ● Twitter等、SNSで騒いでみる –誰かが何か指摘してくれたら自分の勘違いの可能 性が高い ● （私が間違っているだけだ、助かる） –誰も指摘しなかったらバグかもしれないと感じだす ● （ヤバい、世界が間違っているかもしれない）

Slide 12

Slide 12 text

私が間違っているだけで、PHPが間 違っていないなら私が恥をかくだけ。 ヤバいのはPHPがバグっていること。 世界が間違っているから

Slide 13

Slide 13 text

バグを探すのであれば「自分が 間違っている、世界が正しい」と 思って探してる

Slide 14

Slide 14 text

巨大なソフトウェアのバグをど うやって見つけ出すか

Slide 15

Slide 15 text

内部構造を知るべきか？ ● 内部構造を知らないと出来ないか –知ってるとよいが、ユーザーランド でわかるし、全てを理解しなくてよ い

Slide 16

Slide 16 text

何を知らないといけないか ● 特徴がわかれば良いのでは ● それが固まりとなると集合知になる し、歴史になる ● 特徴が変化するときにあれ？となる

Slide 17

Slide 17 text

特徴を理解する ● ここで言う特徴とは –「知ってる」っていう部分 –特徴を集めていく –特徴から挙動を理解していく ● 何が入力されたら何が出力されるかとか あなたの興味のある部分を調べて特徴にしていこう

Slide 18

Slide 18 text

知ってた特徴から見つけたバグ ● 例：mbstring関数の特徴 –PHP 7.0まで、引数にstringを要求されて るのにarrayを入れるとmbstringだけ falseが返ってくる（他の関数はnullが多 かった)

Slide 19

Slide 19 text

知ってた特徴から見つけたバグ ● 例：mb_check_encoding(array()); <= 7.0 7.1 7.2 => FALSE NULL TRUE

Slide 20

Slide 20 text

知ってた特徴から見つけたバグ ● 例：mb_check_encoding(array()); ● 7.3.0RC5でcrashしたので報告した ● https://bugs.php.net/bug.php?id=771 65

Slide 21

Slide 21 text

知ってた特徴から見つけたバグ 特徴を理解し、挙動から調べる いつでもおかしい挙動をバージョ ンが繰り上がるごとに調べていく

Slide 22

Slide 22 text

特徴の理解の仕方 1 ● 特徴を理解する方法として –ソース読む –PHP Internalsのメーリングリストを読んでる –GitHubのPull Requestを購読してる –他にもgit pull してきてコンパイルを毎日やるとかがあ るっぽい ソースコードの変化を調べる

Slide 23

Slide 23 text

特徴の理解の仕方 2 ● 特徴を理解する方法として写経がある –ソースコードの写経をしている、したリスト ● var_dump –zval構造体の理解に役に立った ● debug_print_backtrace –バックトレースの理解に役に立った ● phpinfo –MINFOなど、設定方法などがわかった php-srcがわからないならphp-srcを写経すれば良い

Slide 24

Slide 24 text

写経して知る特徴 ● phpinfoを写経すると、知らない特徴がたくさん出てくる –Windowsでの挙動 ● Architectureという欄が追加されてる ● Compilerという欄が追加されてる –イースターエッグ マニュアルにない挙動がたくさんある

Slide 25

Slide 25 text

写経して知る特徴とバグ ● phpinfoを写経すると、知らない特徴がたくさん出てくる –ソースコードから、phpinfo(INFO_CREDITS);をCLIで実行 すると表示されないことに気がついたので報告した –https://bugs.php.net/bug.php?id=80771

Slide 26

Slide 26 text

見つけたバグとの葛藤 ● phpinfoにバグがあるなんて誰も知らなかったらしく、遡ること 18年くらい前から残ってたバグだった ● そのため、報告する私も「これバグなのか？」ってなった ● このときに「自分が間違っている」と思っているので、「PHP が間違ってるわけ無いだろ」と無視する可能性もあった – 傍観者効果に陥りそうだった、打ち消す必要がある 誰も！！バグ報告していないのである！！とはなりたくない

Slide 27

Slide 27 text

私は間違っているとは bugs.php.netで報告するとき悩む… ● 「それはバグではない」ことがわかったこと ● これを打ち消すときは「それがバグである」ことを意味する ● しかし、現実には「バグではない証拠を見つけられなかった」 となる –無いとは言えない、知らないだけかもしれないから –だから、間違っているとする根拠はソースコードのみ

Slide 28

Slide 28 text

バグ 私は間違っている VS 歴史 コードの 間違い オレは 間違っている 18年 潜んでいた バグ phpcredits()は 正常に動いてる マニュアルは phpcredits()を 参照しろとある PHPが 間違っている はずがない 仮にバグだった として、 後方互換性は？ どこかに 仕様である 証拠はない？

Slide 29

Slide 29 text

最後はもう勢い 結局悩んでても仕方がない、私 はこう思うというのをExpected に書いてSubmitだ

Slide 30

Slide 30 text

バグを指摘した後の影響？ 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);

Slide 31

Slide 31 text

バグを指摘した後の影響？ 2 ● PHPerKaigiでイースターエッグの話をしたので、イースターエッグの修正も 入りました（ChangeLogには載ってない、イースターエッグっぽくてよき） – 来年の4/1にもphpinfo()を各バージョン見くらべようね！ – elePHPantの文化に詳しくなかったから指摘してくれて嬉しい ● 興味あったらさがしてみてね 確かに他にもあるんじゃねって見つけたくなるよね

Slide 32

Slide 32 text

面白いと思ったバグを見つけたら ● そこにヒントがあるかもしれない – あれ？って思ったバグを調べてみよう ● 再現したりして「そしたらこれはどうかな？」ってやってみるとか ● 1個見つかれば多分何個か出てくると思う！ ● 他の人が見つけても、それが学びになるから追いかけると詳し くなれる！ バグを皮切りに色々動くかも！！

Slide 33

Slide 33 text

Fix Typoという貢献 ● バグの一つに、ソースコードに変数名やコメントにtypoがある – 「Fix typo」のようなtypoを修正するPull Requestはよくある – ソースコードを目を皿のように読まないとわからない ● 修正する側もすごいし、受け入れてる側もすごい – 変数名、コメント程度で挙動に影響しないものは、CIをスキップ できるので、「[skip-ci] Fix typo」のようなコミットが多かった typoの修正も貴重な貢献の一つです！

Slide 34

Slide 34 text

変な変更を監視する必要とは ● 2021年3月末、バックドアが仕掛けられる事件があった – [skip-ci] Fix typoでCIをスキップでき、たくさんあったFix typoの一つと して紛れ込ませた – つまり、「Fix typo」の貢献を悪用しながら、CIと人間の目をかいくぐり、 バックドアを仕掛けようとしたという巧妙なもの ● masterへのコミットなので、実被害はphp-srcを開発してる、とか じゃないとないでしょう。 ● 自分が気がついたときは「Revert: Revert: Revert... 」のよう に、Revertが繰り返されたPull Requestがあったとき

Slide 35

Slide 35 text

この事件の影響 ● 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

Slide 36

Slide 36 text

まとめ ● バグは明後日の方向からやって来ることもあるけど… ● まず、注目しているソフトウェアの一部分の挙動を理解すること。数百万のコー ドなんて考えなくていい。興味ある部分を調べてみよう ● 一つの挙動を完璧に理解しよう。それの変化を見たらバグがないか調べよう ● 結局は勢いだし、報告してくれてバグでなかったとしても助かる みんなでバグを報告していこう

Slide 37

Slide 37 text

バグ報告はいいぞ

Slide 38

Slide 38 text

● 2019年5月ごろに3D化しました。 ● コロナ禍でオンラインカンファレンスが中心になっ て、オンラインでしかできないことをやりたいと思って この姿で登壇してます。 この3Dアバターについて ● MagicaVoxelとBlenderを使ってます！今なら色々なプラットフォームがあって3Dアバターを 作りやすいと思います。 ● 3Dアバターで登壇するメリットはこういうのがあります – 顔を見せる必要がない – 自分というキャラクターを出せる、好きになれる – 身振り手振りなどの応用も効かせられる(表示は3tene、手はLeap Motion使ってます)

Slide 39

Slide 39 text

おしまい ご清聴ありがとうございました 参考になれば幸いです。 高評価、チャンネル登録、ツイッターのフォローお願いします