起動キューイングされたタスクのext_tsk

• 回報者: m-arai
• 負責人: m-arai
• 類型: 修補檔案
• 狀態: 關閉
• 元件: (無)
• 里程碑: (無)
• 優先權: 9 - 最高
• 嚴重程度: 5 - 中
• 處理結果: Invalid
• 檔案: 5

細節 回覆

ext_tsk()において、
1. 起動要求がキューイングされている
2. 呼び出す瞬間のスタックの伸びが十分でない
場合、深刻な問題が生じる場合がある。

確認の手段

CRE_TSK(TID_ACTER, {TA_HLNG|TA_ACT, 1, Task1, 1, 256,
NULL});
CRE_TSK(TID_EXTER, {TA_HLNG|TA_ACT, 1, Task2, 2, 256,
NULL});

void Task1(VP_INT exinf)
{
Sci_Puts("Task1: Start.\r\n");

/* Task2 (ext_tsk onlyなタスク)を起動要求する */
Sci_Puts("Task1: act_tsk(TID_EXTER)\r\n");
act_tsk(TID_EXTER);
/* 但し,既にREADYであるため,キューイングされる。*/

/* 1秒間眠る */
Sci_Puts("Task1: dly_tsk(1000)\r\n");
dly_tsk(1000);
/* この眠りによってTask2へのディスパッチが起こる */

/* 生存を主張し続ける */
for (;;) {
Sci_Puts("Task1: Alive!\r\n");
dly_tsk( 5000);
} /* システムが落ちていなければ,約5秒ごとに表示が出る */
}

void Task2(VP_INT exinf)
{
/* いきなりext_tskする */
Sci_Puts("Task2: Start and Exit.\r\n");
ext_tsk();

/* CRE_TSKの段階でTA_ACTなので,Task1でact_tskされてい
る分,
起動要求が1回分キューイングされている。
従って,ここでext_tskしても,1度はすぐ再び起動される筈
である。
ここでシステム死ぬことは,ext_tskのバグの証明に他なら
ない */
}

なるプログラムの実行で、Task1が死なないこと、Task2が2度起
動する
ことが確認されれば問題なし。

添付のパッチはこの問題を解決する。

Ticket History (3/12 Histories)

2003-10-12 23:17 Updated by: m-arai

• File 729: ext_tsk.diff is attached

2003-10-13 09:18 Updated by: m-arai

評語 回覆

Logged In: YES
user_id=1822

書き忘れていたが、添付差分の問題点として、「レディキューへの
接続がディスパッチ1回分保留されるため、仕様から想定されるより
タスクの再起動が遅くなる」というものがある。

2003-10-13 14:59 Updated by: m-arai

• File 730: zomb.diff is attached

評語 回覆

Logged In: YES
user_id=1822

修正2版の要旨は以下の2点。

1. 自タスクを起動する場合、スタックを強制的
に割り込み用に切替えてコンテキストの破壊を
防ぐ。

2. 停止されたタスク実行中から発行される
ディスパッチの場合、コンテキストスイッチは
「切替え」ではなく「変更」になるようにする。

どちらもPACにアセンブラレベルの関数追加
を行なっている。

結果:

Task1: Start.
Task1: act_tsk(TID_EXTER)
Task1: dly_tsk(1000)
Task2: Start and Exit.
Task2: Start and Exit.
Task1: Alive!
Task1: Alive!
…

1版ではレディキューへの接続が
ディスパッチ1回分保留されるため、

Task1: Start.
Task1: act_tsk(TID_EXTER)
Task1: dly_tsk(1000)
Task2: Start and Exit.
Task1: Alive!
Task2: Start and Exit.
Task1: Alive!
…

こうなる可能性もあったが、その点は
改善され、仕様を守れるようになった。

一方、スタックを強制的に切替える
という危険な真似もしていて、
プロセッサによっては問題があるかも
しれない。

2003-10-13 22:24 Updated by: m-arai

評語 回覆

Logged In: YES
user_id=1822

よく考えたら、例えhospac_cre_ctx_asmと現在のスタックが干渉しな
くても、ext_tskの最後のmexe_dspで折角作ったコンテキストが無効
なコンテキストで破壊されてしまうのだった。

即ち、
> 2. 呼び出す瞬間のスタックの伸びが十分でない
これはあまり関係無い。

2003-10-14 21:54 Updated by: m-arai

• File 735: zomb_2.diff.bz2 is attached

評語 回覆

Logged In: YES
user_id=1822

3版:
hospac_swi_ctxの引数の順番を変え、hospac_chg_ctxとコードを
共有できるようにした。
その他細かい点にゆいて整理を試みた。
h83n/arm/sh/ia32についても作業してみた。動作確認をとったのは、
相変わらずh83のみ。armはほぼ間違い無く、ia32は確実に動かない。

2003-10-20 19:13 Updated by: m-arai

評語 回覆

Logged In: YES
user_id=1822

4版:
自コンテキストに対するcre_ctx対策として、ctx_entryでcre_ctxで
潰される分スタックを進めておく案。無駄にスタックを消費するが、
一方で実行中のスタックを強引に切り替える真似はしなくても済む。

2003-10-20 19:13 Updated by: m-arai

• File 742: zomb_3.diff.bz2 is attached

2003-11-01 07:31 Updated by: m-arai

• File 750: mext_stu.diff is attached

評語 回覆

Logged In: YES
user_id=1822

修正4版のsrc/mknl/sys/mext_stu.c部分差替え:
mknl_ext_startup()内の
hospac_swi_ctx(&dmy_ctx, &mtcb->ctxinf);
あるいは
hospac_swi_ctx(&dmy_ctx, &mknl_idlctx);
は、何ら初期化しないdmy_ctxから取得した不定の値をスタック
ポインタとし、そこに現コンテキストの保存を行ってしまっている。
幸運に恵まれていると問題にならないが、致命的な結果をもたらす
可能性がある。
swi_ctx->chg_ctxでこの不具合は回避できる。

2004-10-20 23:14 Updated by: hamayan

評語 回覆

Logged In: YES
user_id=1818

ゾンビ３の日立H8ノーマルモード(src/h83/htc)向けパッチで、
pacctxn.srcの.
EXPORT _hospac_chg_ctxの参照先のラベルが抜けている様です。

2006-01-16 20:59 Updated by: m-arai

• 優先權 Update from 5 - 中 to 9 - 最高

2006-04-21 00:11 Updated by: m-arai

評語 回覆

Logged In: YES
user_id=1822

本件に添付されているパッチには数々の問題が有ります。
それぞれについての追加修正はおそらく行われません。
別の方向性は見えつつあるようなので、そう遠くない将来、
改めて出したいと考えています。
特に削除せず残しておきますが、あくまで参考の為です。

本件に関する議論は、
https://sourceforge.jp/forum/forum.php?thread_id=3528&forum_id=696

2006-05-06 00:10 Updated by: m-arai

• Ticket Close date is changed to 2006-05-06 00:10
• 狀態 Update from 開啟 to 關閉
• 處理結果 Update from 無 to Invalid

評語 回覆

Logged In: YES
user_id=1822

本件に関しては、Bugsへ

[ #8378 ] act_tskキューイング時ext_tskで自スタックを破壊
htpps://sourceforge.jp/tracker/index.php?func=detail&aid=8378&group_id=183&atid
=778

当トラッカーアイテムは放棄されました。