観察日記 2010-04-16

chunky bacon

そーか、whyがいないから、Ruby会議のイラストは募集になったんだ。
実はうちの家内から毎年気持ち悪いと不評だったんだよな。
まぁクセは強い
意味がわかんなかった。
絵の。
chunky bacon!
chunky bacon!
意味は？
意味がわかんない例
もしかして意味は全くない？
あるのかないのかわからない
http://www.aoky.net/articles/why_poignant_guide_to_ruby/images/the.foxes-4f.png
ご覧の通り。
but we did it とか書いてある。
なんだこりゃ？
http://www.aoky.net/articles/why_poignant_guide_to_ruby/chapter-3.html
{hermite} ホワイの(感動的)Rubyガイド :: 3. (漫画のキツネと学ぶ)短時間の(そして願わくは辛くない)Rubyコース
chunky bakonはそんなにきもくない気がする。線がシンプルでアニメっぽいし。
_whyのその他の絵はもうちょっとくどいよね。
オタクっぽいと言われた。

原因は呼出規約と最適化とGCです

http://redmine.ruby-lang.org/issues/show/2821 の件、原因分かったが どう直すべきか分からない。。。
おお、教えてください＜原因
おお
SEGVも確認
なんと
原因は呼出規約と最適化とGCです
ぶ
数え役満
うわあ
push_glob関数で VALUE str から RSTRING_PTR(str)を取り出して使ってるんですが途中でstrが回収される
スタックに載らなくて揮発する変数に乗ってmarkされなくてさようなら攻撃か
GC_GUARDで救えるかなあ。
ここだけならいいけど他にも潜在的脅威がありそうでいやだなぁと。
すばらしい調査ですね
基本的には見つけたら潰すで対処してきてはいるんですが
そこまでに至った過程を是非知りたい
発現条件には{} が入ってることもあります。
呼び出し規約ってことは __cdecl を付けたら治るの？
ruby_brace_expand内のstrが 内部でさらにruby_brace_expandを呼ぶ前後で壊れるのでバッファーオーバーフローを疑ってたらGCまでたどり着きました。。。
最適化でスタックから消されないなら・・・
よく考えたら __cdecl がデフォルトなんじゃないかという気がしてきたけど、僕の記憶違いかもしれません
tail call だからジャンプになってるのかな
VCなのでstdcallなのでは？
WINAPI とか CALLBACK とかわざわざ書いた記憶があって
明示的にVALUEを消さない指定が出来るようにするか、一度コピーするかですが
確かそいつらは __stdcall だったような気がするんですよね
http://www.atdot.net/sp/view/wvrl0l
こんな感じで直るのですかね
パフォーマンスとの兼ね合いもあるので誰かポリシーが分かる方お願いします。。。
RB_GC_GUARD だった
実用上困るような明らかなバグの前にはパフォーマンスは無視されます
ふむ。
http://www.atdot.net/sp/readonly/lxrl0l こんなのを実行すると結果は無茶苦茶だしたまに落ちます
前ちょん切れた。 dirはそれぞれ適当にお願いしますm(__ )m
push_glob は明らかに問題ありそうなコードですねえ
うん。
bzi
RB_GC_GUARDで無事直った
誰だよこれ最後にいじったの、とか言うと俺のような気がするのが辛い。
おおー
ぱちぱち
チケットに返信してくだされば拍手喝采で取り込んで close します
します
r24985 の前からおかしいな
つか、むしろgccなプラットフォームでは誰にでも起こりえる問題だった予感
r24133 は微妙に怪しい
なぜ消した
あー、この頃はちゃんとguardしてたのか。
re-fixとか言ってるけど...
とりあえずlog messageは不適切だ
r17953 で str から RSTRING_PTR(str) を渡すように変わった
{unak} やっぱりぼくですね
当選おめでとうございます
r24127 で volatile をささださんが入れた
2年前とか見事な記憶力
まあなんつーかRSTRING_PTRとかいきなり引数に入れるのが、一般論的に既に危うい。
という知見を得たのがまさにこの話だったような気がする orz
orz
なんでささやんは大丈夫になったように思ったんでしょうね。
re-fix がわからんですね
ささださんが大きくなったからだね
あ、わかった
StringValuePtr は関数に str のポインタを渡すから
そのポインタがそのあと使われる可能性を考えて
勝手にスタックから消すような最適化はできなくなる
ということは、
犯人はnobu
ですね
まあ、re-fix でそんなさりげない直し方をするなら
意図は正しいとして、その際にguardを復活させる必要があった、と。
コメント書いとけという気もする
まあ、多人数開発(または長期間開発)の弊害が出た例ですね。
こんなこともたまにはある。
GCはマルチスレッド並に難しいなぁ
非常に興味深い事例