# MochiLOGd_

 デバッグログ強化を進めたお陰でタイトルの通り原因判明に至った。 以下、なりゆき。 (1) デバッグログをメモリ上にも吐き出すように機能追加 (2) TripleFaultを再現させるも、吐き出したメモリ上のログが破壊されていることに気づく (3) GDB繋いでログメモリ先頭アドレスにwatchpoint設定して監視するも、引っ掛からない 　⇒つまり、別の仮想アドレスからメモリ破壊していることに気づく (4) ページマッピング箇所にトレースログを仕込み (5) どんどんページに割り当ててる物理アドレスが加算されていることに気づく 　⇒つまり、メモリリーク (6) 怪しい所にどんどんトレースログ追加していき原因判明 直接的原因１： 　プロセスのヒープ領域を縮小する時に、ページマッピング解除は行っているが、割り当てている物理メモリを解放していなかった。 直接的原因２： 　普通に設計上固定的に使っている物理メモリ領域をカーネルの物理メモリ管理くんが未使用と認識していて、割当てを行っていた。 直接的原因１の動機的原因（根本）は、後で実装すればいいや精神でテキトーに実装したからだな・・・。ページマッピング解除時に関数のインタフェース仕様が理由で割り当てていた物理メモリアドレスがわからないから解放ができず、割と大がかりな構成変更が必要だったから後回しにしていたようだ。なんにも残してない自分が悪いね。個人開発でもTODO管理やチケット管理ってやっぱ必要だと思う。うん。 直接的原因２のほうは・・・なんでだろうね。どう考えていたか覚えていない。 あー超スッキリした！メモリマネージャ大改造しよ。これが当面の目標。