(8632)
8632：
Tra_TAG.def のバグ
投稿者：
konno
2018/12/02(日) 00:00
コメント数 1
使用中の Tra_TAG.def に、致命的なバグがありました。(>_<)
WEBデータなどでは、1行の長さがとても長く改行の無い文章がありますが
Grep で検索したワードの一覧でも長いものがあり、これを Tra_TAG.def で
タグジャンプしたら、マクロ領域を壊して、VTDOSが落ちました。
オリジナルの Tra_TAG.def でも同様です。
オリジナルVZでも高橋版VZでも同様でした。
落ちるデータは、We140*22行あり、1行で3080文字を超えます。
3分割で改行を入れると落ちないので、一時バッファ溢れだと思いますが
今見ても全く分からないので、取りあえず泥縄で対策しました。
Tra_TAG.def の冒頭に
dn[+, #] #? #< i=ly, #> i=(ly-i)*we+lx, ;1行の長さチェック
(wn==0&&i>=255)?{ #< &x(254) #m #e} ;コンソール&行255以上なら改行
#< dn], ;
これを入れたら取りあえず問題なくなりました。
:A si=r-1, di=pq..134+100, i3, ;フルパス部分を di へ取り出し
この辺が怪しいと思うんですが、全く読めない。(;_;)
困ったときのFGALDC から、えむしさんの記事を引用します。m(__)m
> 07047/07051 xxxxxxxx えむし ＭＡＰ
> (15) 97/07/23 09:02 07007へのコメント
> とりあえず、私が持っている gz の MAP を書いておきます。
--------------------------------------------------------------------------
gz:0000h+---------------+
| psp |
0100 +---------------+ ORG
0110 | | ◆pc
| |
| |
| wseg |
0206 | | 変数テーブル
028E | | ◆pq(pc+382)
| |
+---------------+ pq+194(pn-156)
03EC | | ◆pn(pq+350)
0442 | | fg(pn+86)
04D2 | | ◆mg(fg+144)
| dseg |
05B9 | | ◆pv(mg+231)
062A | | ◆vp(pv+113)
| | ↓
0690 +---------------+ vp+102(pq..99) -- ここまでvzと同じ
| | コマンドキーテーブル
08AA | | (pq..110)コマンドキーの説明書き
| |
0F73 +---------------+ mh
| macro_buf |
| |
〜 〜
〜 〜
| |
AFD2 +---------------+ pq..131 pu-bc：削除バッファ
| cbuff Bc byte |
B3D2 +---------------+ pq..132 pu：スタックバッファ
| ubuff Bu byte | マクロ用配列バッファ
| stack ↑ | スタックメモリの若い方へ積み上げる
B452 +---------------+ pq..133 pu+bu：表示文字列バッファ
| pfbufp 84byte | &m の時、ここでいったん文字列にしてから表示
B4A6 +---------------+ pq..134 pu+bu+84：tmpbuf
| tmpbuf 256byte| コマンドラインのラインバッファなどに使われる
B5A6 +---------------+ pq..135 pu+bu+84+256：tmpbuf2
|tmpbuf2 256byte| エイリアスの文字列はここで一度展開
B6A6 +---------------+ pq..136 pu+bu+84+256*2：tmpbuf3
|tmpbuf3 160byte| ディスク転送アドレス(DTA)
| | &? は、ここで一度展開してから出力
+---------------+
| |
BA2C +---------------+ pq..142、pn..-33 pu+bu+1498
| | コンバートされた検索文字列のバッファ
BAAC +---------------+ pq..143
| | コンバートされた置換文字列のバッファ
BBB4 +---------------+ pq..141（pq..141）
| | &^用のオプションの初期値
CF2C +---------------+ pq..146
| asm_stack? |
D02C +---------------+ pq..147
DADC +---------------+ pn..-27(pq..148)wm+228
| line_buf | (先頭はCR/LF実質wm+230が始め)
| |
EADC +---------------+ pq..149
|tmpbuf4 256byte| 256 バイトのテンポラリ領域（ラインバッファの直後）
| | &z 等のマクロ組込時以外は比較的自由に使用できる
+---------------+ pq..149+256 ラインバッファの終端
| |
引用ここまで --------------------
pq..134 を一時ワークとすると、最大でも256byte
あとは、tmpbuf2 tmpbuf3 合わせても、672byte で、それをも突き破って
マクロ領域を壊してしまったと思われます。
(8632)
8633：
Re: Tra_TAG.def のバグ
投稿者：
としき
2018/12/02(日) 11:54
参照先：http://toshiki.la.coocan.jp/
8632 番 konno さんへのコメント コメント数 1
> タグジャンプしたら、マクロ領域を壊して、VTDOSが落ちました。
タグジャンプの際に、即時というか、すぐに落ちたということでしょうか。
時間差というか、しばらくしてから落ちるのに比べれば、切り分けは楽かと。
いや、もちろん、どんぐりの背比べ、という言葉もありますが。
約3000バイトを３分割したら落ちなくなったということは、約1000バイトならOK
ということですよね。なら、何バイトなら落ちるか、というあたりは追及する
必要はないのでしょうか。私は、そのバイト数からポイントが特定できるような
気がするのですが、それを追及する必要はないとか、追及しても意味がないと
いうことであれば、その理由をご教示いただければ幸いです。
- No.8633 -
このTreeへ
コメント元:8632 へ
[リストへもどる]
soft
(8632)
8634：
Re^2: Tra_TAG.def のバグ
投稿者：
konno
2018/12/02(日) 17:52
8633 番 としき さんへのコメント コメント数 1
> タグジャンプの際に、即時というか、すぐに落ちたということでしょうか。
> 時間差というか、しばらくしてから落ちるのに比べれば、切り分けは楽かと。
ああ、そうですね。それを書くのを忘れてました。
直ぐには落ちないです。
検索窓やオープン窓などのヒストリーがマクロコードになってしまいます。
その一行窓を閉じた時に落ちることもあれば、なかなか落ちないこともあります。
[ESC]+M でマクロ一覧を見ると、VZ.DEF と VZFL.DEF 以外は消えてしまって
いたりとか、色々な事象が発生します。
今頭がウニでマクロコードが読めないので、上記の事象でバッファ溢れと推測しました。
私はやっぱり泥縄式人なんですね。
暫定の対策も、コンソールのみとか、カーソルが一番下にあったときとか考えてないし
私の環境で動けばいいやという程度です。
検索ワードピッタリにジャンプできないのは仕方がないですかね。
まあ、長すぎる行は改行しとけという事で。
> 約3000バイトを３分割したら落ちなくなったということは、約1000バイトならOK
> ということですよね。なら、何バイトなら落ちるか、というあたりは追及する
> 必要はないのでしょうか。私は、そのバイト数からポイントが特定できるような
> 気がするのですが、それを追及する必要はないとか、追及しても意味がないと
> いうことであれば、その理由をご教示いただければ幸いです。
追及すれば出来ないことは無いかもですが、今は全然読めないので止めておきます。
どなたかキチンと対策が出来るようなら是非御教示願います。m(__)m
- No.8634 -
このTreeへ
コメント元:8633 へ
[リストへもどる]
soft
(8632)
8635：
Re^3: Tra_TAG.def のバグ
投稿者：
konno
2018/12/02(日) 23:44
8634 番 konno さんへのコメント コメント数 1
> 暫定の対策も、コンソールのみとか、カーソルが一番下にあったときとか考えてないし
案の定駄目でした。
dn[+, #] #? #> #< &x(255) ;1行の長さチェック
(cd==$d)? >a ;カーソル255桁目が改行なら >a
(wn==0)?{ #< &x(254) #m #e} ;コンソールなら254桁目に改行挿入
:a #< dn], ;
冒頭のルーチンを上のに変更したら、うまく動いているようです。
(8632)
8636：
Tra_TAG.def 改 k04
投稿者：
konno
2018/12/04(火) 23:17
8635 番 konno さんへのコメント コメント数 1
> 冒頭のルーチンを上のに変更したら、うまく動いているようです。
不要な部分を整理して、下記のようになりました。
#] #? #> #< &x(255) ;バッファ溢れ対策 行の長さ255以上？
(cd!=$d&&wn==0)?{&x(254)#m#e}#< ;コンソールなら改行挿入
Tra_TAG.def v16k04 として、#test72 に置いてきました。
ちなみに、Tra_TAG.def のルーチンは、vz16t.def にも使われていました。
> 12113/12115 xxxxxxxx くらと vz16t.defの雛形
> (15) 98/11/03 00:06 コメント数：1
>
> RE:MES 13 #04911 高橋 洋光 さん
>
> vz16t.def の雛形を作って見ました。
中身は同じものなので、バグも同様でしょう。
(8632)
8637：
Tra_TAG.def 改 k05
投稿者：
konno
2018/12/25(火) 03:13
8636 番 konno さんへのコメント
> Tra_TAG.def v16k04 として、#test72 に置いてきました。
WEBデータによっては上手くいかない場合がありました。
改行コ−ドが、$0a のみの場合とかあるんですね。
それで、ct を思い出して、以下のように変更しました。
; (cd!=$d&&wn==0)?{&x(254)#m#e}#< ;コンソールなら改行挿入
(ct!=1&&wn==0)?{&x(254)#m#e}#< ; cd を ct に変更、各種改行に対応
TRA_TAG5.DEF として、VZマクロの部屋に置いてきました。
御使用時はリネームしてください。