- 1 名前：名無しさん＠お腹いっぱい。 [04/10/11 11:01:02]
- はたらけど はたらけど猶 わが生活
楽にならざり ぢつと手を見る
>> Shut up and code!!!
前スレは>>2-5あたり
- 413 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/01/14(土) 22:24:38 ]
- >>412
libcのmalloc(3)を切り替えたよ。今はデバッグ、検査、統計収集用のオプションが
全部有効になってるから、プログラムは遅くなるしメモリも余計に食う。移行期間の
バタバタがおおよそ終わったらここらへんのは切れるから。
パフォーマンスが気になるなら、src/lib/libc/stdlib/malloc.cの中にある下の
いくつかをundefineして。これらのせいでプログラムが遅くなって、メモリも
余計に食ってるんだ。
MALLOC_DEBUG MALLOC_STATS MALLOC_REDZONES
もしmallocがらみの実行時エラーを見つけたら、malloc(3)でチューニング用の
フラグを調べて関係あるのを使いながら、問題の種類をみきわめてほしい。特に
A J Q Zフラグは便利だね。この実装が見つけるアプリケーションのバグは
- 414 名前：名無しさん＠お腹いっぱい。 mailto:sage [2006/01/14(土) 22:37:52 ]
- * バイト境界に対する誤った仮定: このmallocはたとえ非常に大きい領域の割り当て
についても16バイト境界しか保証しない。正当だけど、あまり一般的じゃない。
phkmallocはここらへんがとても寛容だった。もしこういうバグをみつけたら
posix_memalign(3)を見て直してね。
* バッファオーバラン: このmallocはboundary tagを使っているので、割り当て
の外側に書き込むとmalloc内部のデータ構造を壊す可能性がある。小さいオーバ
ランはredzoneで検出できるけど、大きいのは無理だ。
この変更によって沢山の問題の報告が来るだろうと思う。その場合、たいていは
アプリケーションのバグだと思うけど、malloc自身のバグという可能性もある。
みんな、広い心で原因の究明に取りくもう。
|
 |
