> The bug was only triggered on sparc64, since it uses 8k pages. > The default yacc stack size for C++ is 24 * 200 = 4800 bytes, > which is larger than a page on most platforms. > In this case malloc returns a page aligned object, > no moving of the allocation inside a page occurs. sparc64の8kページで起こるバグって言ってるけど、ようするに デフォルトスタックより大きいページだと発生するみたいですね。
> The bug was only triggered on sparc64, since it uses 8k pages. sparc64でしか起こらないバグ、と言うことは単にyaccがsparc64で動作させることを 想定していなかっただけじゃないのかな？ と言うか、yaccが作られた時にsparc64がありましたっけ？＜あまり歴史知らない
やっく☆でかるちゃー (スコア:5, 興味深い)
> The default yacc stack size for C++ is 24 * 200 = 4800 bytes,
> which is larger than a page on most platforms.
> In this case malloc returns a page aligned object,
> no moving of the allocation inside a page occurs.
sparc64の8kページで起こるバグって言ってるけど、ようするに
デフォルトスタックより大きいページだと発生するみたいですね。
現実の環境が、開発時に想定出来た範囲を超えたから表面化したバグってとこですか。
ってことは、今後もソフト屋の想像力を超
これってバグと言うのか？ (スコア:1)
sparc64でしか起こらないバグ、と言うことは単にyaccがsparc64で動作させることを
想定していなかっただけじゃないのかな？
と言うか、yaccが作られた時にsparc64がありましたっけ？＜あまり歴史知らない
作成時に存在しないアーキテクチャに対しても対応しないとバグと言われるなら、
全てのプログラムが将来バグを含むと思うけど。
＃元々sparc64上の動作を想定して作成されて、かつ問題が発生したなら
＃バグとは思うが。。。
Re: (スコア:5, 参考になる)
> 想定していなかっただけじゃないのかな？
> と言うか、yaccが作られた時にsparc64がありましたっけ？＜あまり歴史知らない
ちゃいます。アロケートしたメモリの外側をアクセスしているので、言語仕様に照らしてもバグと言いきれるでしょう。
たまたま、小さなページサイズのアロケーションでは (そして既存のアロケータの多くでは)
アロケートした領域の後ろに余裕があったので不正なアクセスに誰も気づかなかったというだけです。
なので
> 作成時に存在しないアーキテクチャに対しても対応しないとバグと言われるなら、
> 全てのプログラムが将来バグを含むと思うけど。
そういう話ではないのですよ。
でもvalgrindとかpurifyみたいなメモリチェックツールでは今まで見つからなかったのかなあ?
Re:これってバグと言うのか？ (スコア:1, 興味深い)
て、事例もあるから、表面的には問題なく動作する古いソースにチェックツールをかけて、
修正しまくるのも、どうかとは思うけどね。
Re: (スコア:0)
ちゃんと調べて直せば問題なかったわけですよ。
チェッカを掛け捲ること自体は問題ないよ。