MochiOS開発記＠当面の目標

-
突然のフリーズ。 カーネルログを見ても解析困難。
というわけで、このバグ修正を当面の目標にしよう。
INT14なのでページフォルトなのだけど、誰かがメモリ破壊してる気がするなぁ。。。
とりあえず、カーネルログのレベル実装してもうちょい情報増やしてみよう。

コメント

コメントを投稿

このブログの人気の投稿

MochiOS@仮想ファイルシステムの作成part7

-
イメージ
MochiOS@仮想ファイルシステムの作成part7 前提知識無しで作るなんちゃって仮想ファイルシステムpart7。 開発日記です。独り言です。 これまでのあらすじ part 内容 0 仮想ファイルシステムを作りたい宣言をする。 1 ざっくり仮想ファイルシステムの機能を決める。 が、機能呼出し先の仮想ファイルシステムのタスクIDをどう取得するかという問題に気付く。 2 カーネルにタスク名登録機能を実装した。 これでタスク名からタスクIDを取得する事が出来る様になるハズ、なので試したいが試す方法が無い事に気付き、ログ出力タスクの開発を宣言する。 3 ログ出力の為に使うvsnprintf()の仕様を調べる。 4 ログ出力タスクを開発してタスク名からタスクIDの取得機能が正しく動いている事が確認できた。 5 mount機能を実装した。たぶんできてる。 6 FDどうやって管理しようかー。メッセージのやり取り制御を状態遷移で制御しようかー。とか考えて、open機能を実装した。たぶんできてる。 writeの仕様を考える 今回はwrite機能を作ります。 仮想ファイルサーバとしては、openもwriteもあんまりやること変わらないハズ。なので簡単にできるかな～と思っている。 あ、キャッシュなんて何にも考えていませんからね。 ユーザタスク mvfs シリアルポートドライバ ローカルFD テーブル参照 write要求( グローバルFD, アドレス, データ, データサイズ ) グローバルFD テーブル参照 vfsWrite要求( グローバルFD, アドレス, データ, データサイズ ) デバイス書込み vfsWrite応答 write応答 書込みアドレス更新 ユーザタスク mvfs シリアルポートドライバ シーケンスの順番は何も変わらず、渡すデータとちょっと間にやる事が変わったくらい。 （こうやってシーケンスにしてみると良く分かるのだけど、データのコピー回数の多さ。マイクロカーネルだとメッセージパッシングが主なデータのやり取りとなる（？）わけだけど、４回のデータコピー（ユーザタスク→カーネル→mvfs→カーネル→シリアルポートドライバ）が走るので性能...
続きを読む

git@よく使うコマンド早見表

-
git@よく使うコマンド早見表 gitでよく使うコマンドをまとめる。 add コマンド 説明 git add . ワークディレクトリ配下全てのファイルをステージ（インデックスに記録）する git add <ファイル> 指定したファイルをステージ（インデックスに記録）する git add -u ワークツリー内でバージョン管理中の全てのファイルをステージ（インデックスに記録）する branch コマンド 説明 git branch ローカルブランチのリストを表示する git branch -r リモートブランチのリストを表示する git branch -a ローカルブランチとリモートブランチのリストを表示する git branch <ブランチ名> 指定したブランチを作成する git branch -d <ブランチ名> 指定したブランチを削除する checkout コマンド 説明 git checkout <ブランチ名> 指定したブランチに移動する git checkout -b <ブランチ名> 新しくブランチを作成してそのブランチに移動する clone コマンド 説明 git clone <リポジトリアドレス> リポジトリアドレスからクローンする git clone --recursive <リポジトリアドレス> リポジトリ内のサブモジュールもクローンする commit コマンド 説明 git commit コミットする（コミットログを編集するエディタが起動する） git commit -m <コミットログ> 指定したコミットログでコミットする git commit -a git add -uとgit commitを連続して実行する config コマンド 説明 git config --list 設定を確認する git config --global core.editor ...
続きを読む

MochiOS開発記＠突然のTripleFaultの原因判明！

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