Deno のめっちゃ難しいバグを修正した - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2022年4月、Deno に以下のバグが報告されました。 fetch API を使って 300KB ぐらいあるファイルをアップロードすると、一定確率でアップロードされたファイルが壊れるというバグの報告です。 報告者によれば、1.20.6 まではバグは発生しておらず、1.21.0 から発生するようになったという事です。1.20.6 の次のリリースが 1.21.0 なので、パッチバージョン1個分まで、バグの発生時期が特定されている状態です。 fetch 周りは自分はほぼ実装していないので「担当範囲ではない」感覚だったので、普通にスルーしてい

[t-tanaka]

こういうバグの原因を突き止めたとき，思いっきり脳汁がドバドバ出ますよね。

[mohritaroh]

「ほぼ4年近く」「ずっとバグっていたものの」「パフォーマンスチューニング作業によって、ストリームの上流側が下流側より有意に速い状況が初めて生まれたためについに顕在化した」すごい

[mohno]

「この issue はきちんと再現コード付きで報告されている issue でした」←まあ、でも、これは大きいよねぇ。

[shunkeen]

共有メモリは人類どころか計算機にも早すぎたのか。。。所有権をめちゃんこ気にするRustで作られたはずのDenoのライブラリに、この手のバグが入り込んでいるのを見ると、なんだか皮肉を感じる

[dsl]

まず再現させて、再現条件を絞り込み、次に現象の起きるようになった変更を特定してからバグの当たりをつけるといういいお手本だ

[K-Ono]

プログラマはタイピングではなく腕を組むのがメインの仕事というのがよくわかる記事でした。すごい。

[razokulover]

これ発見した時気持ちよさそう

[nmcli]

これ特定できた時はさぞ嬉しかっただろうなって

[sora_h]

これRustレベルなら普通にコンパイラが怒ってくるけどTypeScriptでは防げないしまぁ起こるわなぁという感じだ…。ArrayBufferパフォーマンスを取るためにこういうAPI用意してるのかな。足撃ちそう。

[uehaj]

ジェネレータ関数からループ外で割り当てたバッファを返すとそれはジェネレータ関数の呼び出しをまたがって共有されあたかもCのstaticローカル変数のような挙動をする。毎回新しいバッファを割り当てて返すべし

[soratokimitonoaidani]

すげーな これ見つけた瞬間走り回りそう

[igrep]

再現コードはなるべく小さくしよう、というのは一つ教訓として言えそうね

[mojimojikun]

( ･∀･)つ〃∩ ﾍｪｰﾍｪｰﾍｪｰ (自分が関与していない根深いバグの話は本当に純粋に面白くて良いなぁなどというゲスな楽しみ方をしてしまった)

[aike]

推理小説みたいでめっちゃ面白い。Who done it? これだけ難易度の高いバグの修正が1行×2箇所というのもバグ修正の定量的な業績評価が難しい点でもある。

[shikiarai]

あとで読み直す

[strawberryhunter]

ソケットや非同期はAPIだけ見て理解した気になると痛い目を見る。

[hatest]

こういう、適当な条件がそろわないと孵化（顕在化）しない不具合は、バグ(虫)じゃなくて卵のようだ

[rokujyouhitoma]

いい

[rryu]

要は共有バッファを返すタイプのスレッドアンセーフなのだが、yieldだと同期的に使ってくれそうというイメージがあるからなのかメソッドを見ただけではなかなか理解できない。

[fukken]

:+1:

[Pasta-K]

これの原因見つけられるの凄い、発見したとき感動しそう / 分かる "再現コードの中で動いてるパーツが多すぎることはメンテナから放置されやすい一因になります"

[maneman8000]

修正後で毎回バッファを new する効率がちょっと気になったけど使用側で buffersize 変えて最適化してくれという話なんやろうな

[pwatermark]

非同期はすごく有難いんだけど、トラブった時にどこが原因か分かりづらくなるのが困りどころよね 特に古いコードが非同期に関する考慮漏れされてること、結構多いので

[hogashi]

難しい

[SundayIsEveryday]

昔組込み開発で体験した不具合挙動の修正を思い出した。マイコンの高温(動作保証内)での挙動がマニュアルと異なっていて不具合につながったんだけど、設計変更で表出したから当初何が原因か全く分からなかったなー。

[takc923]

これは確かにめっちゃ難しい

[YaSuYuKi]

JavaでString#substringを使うとメモリリークする問題を思い出した。JavaではStringはイミュータブルなのでメモリリークどまりだったが、コピーではなく実体を渡す点は同じ https://takahashikzn.root42.jp/entry/2013/12/24/014122

[tmdtky]

つよつよ

[gfx]

バグが出るきっかけが問題箇所と全然関係ないとつらいね。修正的には s/subarray/slice/ のほうがよいかも → pull-req作った https://github.com/denoland/deno_std/pull/2748

[mizdra]

おもしろい

[yosuke_furukawa]

なるほど、たしかに難しい。

[t_f_m]

"ずっとバグっていたもののおそらく現実的なユースケースでバグが顕在化する例が存在せず" (略) "ストリームの上流側が下流側より有意に速い状況が初めて生まれたためについに顕在化したという事のようです"

[yarumato]

“このissueはきちんと再現コード付きだがかなり長いコードで、問題がどこかがパッと見て分からない。メンテナから放置されやすい一因。とりあえず、再現コードのリファクタに取り掛かる。問題の箇所を絞る”

[jay-es]

"再現コードの中で動いてるパーツが多すぎることはメンテナから放置されやすい一因になります"

[sigwyg]

これは達成感すごいだろなー。エンジニア人生でずっと誇れる一例になるのでは

[beejaga]

read buffer 使い回しは教科書実装なので subarray がコピーを返すと勘違いしたような気がする

[helldeath]

内部挙動分かってないと突き止められなくない？すごいね。

[nao-bt]

こういうロジカルな調査報告は、勉強になるなぁ。

[door-s-dev]

あのバグ気になるけど自分の担当じゃないからな〜とかはあるある

[hush_in]

すごい