[OSASK 720] Re: ssizz1.

[Koyanagi Masaaki <Koyanagi.Masaaki !Atmark! nifty.ne.jp>]

小柳です。こんばんは。

Hidemi KAWAI wrote:
> 
>   こんばんは、川合です。
> 
> Koyanagi Masaaki さんは 2000/06/01 23:47:51 の「[OSASK 711] Re:
> ssizz1.」で書きました：
> 
> >> に、TAPIが急におかしくなって、悩まされてしまったのです。・・・し
> >> かも、情けないことに、TAPIは全くバグがなく、単に僕の勘違いだった
> >> のです。丸一日がこれに費やされました。
> >さし使えなければ、具体的に教えて下さい。技術勉強になるかもしれないので。
> 
>   差し支えはないので、お教えいたしますが、あまりにくだらないので
> 技術的な勉強にはならないでしょう。

そんなことないです。とても興味深く読みました。
ここまで詳しく書いて下さってありがとうございます。

>   まず、ssizz0とssizz1とは、内部的には大きな違いがあります。ssiz
> z0は全タスク数が４つですが、ssizz1は全タスク数が６つです。その内
> 訳は、以下のようになっています。
> 
>   ssizz0
>     ・count up - 1
>     ・count up - 2
>     ・count up - 3
>     ・そのほかの全てをこなすビッグタスク
>   ssizz1
>     ・count up - 1
>     ・count up - 2
>     ・count up - 3
>     ・music player
>     ・scratch pad
>     ・そのほかの雑用（入力切り替え処理など）・・・シェル的存在

ssizz0の「そのほかの全てをこなすビッグタスク」は、ssizz1の
scratch pad+雑用ということですね。
ssizz0ではscratch padのみのタスクは存在していなかった、と。
マウスカーソルを動かすのも雑用タスクですよね。

>   この移行作業中に、トラブルが起きました。メモによると5/30の出来
> 事です。・・・なんと、入力をかちゃかちゃと切り替えると、不意に、
> カウンターが停止してしうのです。

ちなみにこれはOS全体が停止したということ（カーネルパニック）
ですか。

>   そこで、原因を探るべく、調査が始まりました。カウンターがとまっ
> てしまう原因は、複数考えられます。
> 
>   １．timerがなんかの拍子に暴走した。
>   ２．TAPIが狂って、時分割マルチタスクできなくなった。
>   ３．アプリケーションがバグって、高い実行レベルにとどまっている
>       。
>       などなど・・・
> 
>   で、地道な調査の結果、このカウンター停止は雑用タスクから"scrat
> ch pad"タスクへカーソルブリンキング停止シグナルを送信した直後だ
> けに起きることがわかりました。それで、タスク間通信ルーチンが一番
> 怪しいと、目星をつけました。

なるほど、「雑用タスクから"scratch pad"タスクへカーソルブリンキング
停止シグナルを送信」というのが雑用タスクがOSASKのシェル（的存在）
であり、自らの役割を果たしているということですね。

>   それで、ソースのあちこちにブレークポイントを仕掛けて、タスク間
> 通信後に何が起こっているのかを調べました。このブレークポイントの
> セットは、素敵なデバッガがあるわけではないので、ソースを直接いじ
> って、レジスタの内容をダンプさせるルーチンに分岐させているだけで
> す。俗に言う、printfデバッグってやつですね。

私が関わったVFAT-jp（そういえば橋さんのページの更新情報に妙な（笑）記述
が）でもソース中に"PRINTK"を挿入してprintfデバッグをやったりしました。

>   それで、地道に流れをたどったところ、数字時間後に、ついに、TAPI
> が悪いと分かったのです。雑用タスクから"scratch pad"にカーソルブ
> リンキング停止シグナルを送信したあと、すぐに雑用タスクはスリープ
> するのですが、このスリープが効いていないのです。それで、ソースを

スリープが効かないというのは、雑用タスクが起きたままになる
ということでいいでしょうか。

> じっと見て、僕は考えました。スリープが失敗してしまう理由というの
> が分からなかったのです。TAPIのソースを引っ張り出して、すみからす
> みまでアルゴリズムを洗いましたが、そんなことは起きるわけがないの
> です。・・・そうは言っても起きているわけで、ああ、僕のプログラミ
> ング能力もここまでかと、あきらめモードに入りました。それで、とり
> あえずブリンクはやめて、この問題はソース公開のときにTAPIを作り直
> すことで解決させよう、と何度も思いました。でも、そのたびに、いや
> 、そんなことじゃだめだと、考え続けたのです。

ここがデバッグで一番苦しい時ですよね。私だったら、ここで一端
終了して気分転換か眠るかしてると思います。

>   ・・・くたくたになったころ、ふと、思いました。そういえば、TAPI
> の初期設定のところで、タスク数の設定があったよなあ。あれ、ちゃん
> と増やしておいたかなあ？うん、多分増やしたな。・・・ま、一応確認
> しておくか・・・。・・・あれ、ssizz0のときと同じ設定になっていた
> よ。じゃあ、ちゃんと増やしておこう。・・・あーあ、こんなところを
> 修正しても「不眠症バグ」（スリープできなくなったから、こう呼んで
> いたんです）には関係ないよなあ。なんでだろう。どうしてここのポイ

疲労が極限に達しているのがひしひしと感じられます。
この時点ではバグの要素に気づいても、その原因を考えられる状態ではないと。

>   さて、日が昇りはじめる時刻になって、最後にコンパイルし直して、
> 実行して、もう寝ることにしました。・・・すると、奇跡が起きて、不
> 眠症バグは直っていたのです。その時のメモ。

バグが取れたり、方法が分かったりするのはまさにこんな感じですね。

>   「・・・よくわからないうちに、直った。もしかして、本当にタスク
>     数を間違えたのが原因なのか？」
> 
>   「めでたいが、なんだか非常にくやしい。」
> 
>   ちゃんちゃん。

川合さんのこんなメモがいっぱい書かれたノートを見るのもおもしろいかも。

>   これに懲りて、すぐにTAPIの初期化ルーチンの自動化（タスク数を数
> えるとか）をしたのは、言うまでもありません。

こういう自動化ってバグを防ぐためにとても重要だと思います。

> >デバッグはシステムコンソールにメッセージを表示してやっているので
> >しょうか？ssizz1のデバッグモードに入るオプションがあったりして。
> 
>   するどい！・・・あまりにも鋭い指摘です。デバッグモードに入るオ
> プションはないですが、それに相当する隠し機能が存在しています。メ
> モリの好きな場所を覗く機能です。16バイトずつしか表示しませんが。

やった！鋭い指摘ができた。
今後も鋭く迫れるようにがんばります。

>   "scratch pad"で、「dump 0」と入力して、Enterを押してみてくださ
> い。「d」の前にスペースがあってはいけませんし、dumpは必ず小文字で
> 入れてください。後ろの数は16進数です。これは、そんなに厳密なエラ
> ーチェックをしているわけではありません。変な入力をすれば、暴走す
> るかもしれません。だから、秘密です。

dumpという命令のみを解釈するシェルが動いていると言えないこともない
ですね。このメールを出した後で早速試してみます。

それでは。


--
小柳 雅明(Koyanagi.Masaaki !Atmark! nifty.ne.jp)