熊猫さくらのブログ: お知らせ： TOMOYO Linux 1.7.1 にメモリリークの不具合が発見されました。（情報元のブックマーク数）
TOMOYO Linux 1.7.1p1がリリースされているみたいです。かなりメモリリーク対応というか仕様を変えた関係で苦労をされたみたいです。心のこもったBlogの一文。
カーネル 2.6.31 にメモリリーク検出機能（ CONFIG_DEBUG_KMEMLEAK ）がマージされたことに伴い、 TOMOYO 1.7.0 では TOMOYO 独自のメモリ使用量カウンタを廃止したのですが、実は CONFIG_DEBUG_KMEMLEAK の扱いに苦労しています。
お知らせ： TOMOYO Linux 1.7.1 にメモリリークの不具合が発見されました。: 熊猫さくらのブログ
というのも、メモリリーク検出機構が有効化されるまでに発生するメモリ割り当て処理を記憶しておくためのトレース用バッファが不足して自動的に無効化されてしまう（そのため、本人は有効にしているつもりでも実際には機能していないので検出できない）とか、 SLAB アロケータを選択した状態で特定のデバッグオプションと組み合わせて使うと（無限再帰呼び出しにより）スタックオーバーフローが発生して起動不可能に陥るとかしているためです。デバッグオプションをなるべく有効にしながらメモリリークの検出も行うというのは試行錯誤が必要でした。
一昨日リリースされた 2.6.33-rc1 では有効な状態で起動できるようになり、 TOMOYO の処理の中でメモリリークが起こっているらしいことが判明しました。しかし、スタックトレースの出力が示している関数の中の何処が間違っているのか悩みました。スタックトレースはアクセス制御が有効でも無効でも呼ばれる関数の中で割り当てられた４ＫＢのメモリが解放されていないと報告しており、４ＫＢのメモリを割り当てている箇所は１つしかありません。しかし、デバッグ文を挿入して割り当てと解放の回数をカウントしてみても問題点を見つけられなかったため、誤検出ではないかと思いました。ところが、テストプログラムを作成しても再現できないため、他の TOMOYO の関数ではないかと疑い始めました。そして、アクセス制御を有効にしないとメモリリークが発生しないことを突き止め、環境変数のチェックを行う関数で発生していることが判明したのが昨夜のことです。環境変数のチェックを行う関数に対して明示的に noinline 指定をしていなかったために、コンパイラがアクセス制御が有効でも無効でも呼ばれる関数の中に inline 展開してしまったことにより、アクセス制御が有効でも無効でも呼ばれる関数の側ではなく環境変数のチェックを行う関数の側に問題があることに気づくのに手間取ってしまいました。はぅ〜、難しいなぁ。
