hra1129 / msx_basic_compiler

MSX-BASICコンパイラ
MIT License
22 stars 2 forks source link

IF文中にDIM命令が存在すると正常に実行されない #5

Closed NasubiKT closed 7 months ago

NasubiKT commented 8 months ago

下記サンプルコードをコンパイルし実行すると、150行目を実行した直後に暴走します。 210行目をコメントアウトすると、正常に終了します。 サンプルコードでは210行目が実行されることはありませんが、コメントアウトしないと暴走します。 msx_bacon.exeは、2024年01月13日15:00頃にダウンロードしたバージョンで確認しました。

100 SCREEN1,0,0:COLOR15,0,0:WIDTH32:KEYOFF:DEFINTA-Z
110 IO=0
120 '# READ SPRITE
130 SD$=""
140 FOR I=0 TO 7:PRINT "I=";I:
150  READ R$:PRINT R$
160  SD$=SD$+CHR$(VAL("&H"+R$))
170 NEXT I
180 END
190 '# SUB Routine
200 PRINT "Start SUB Routine"
210 IF IO>10 THEN DIM DS$(IO)
220 RETURN
230 '# DATA
240 DATA EE,C2,82,00,82,86,EE,00
hra1129 commented 7 months ago

確認しました。最新版でも、DS$() を使っているわけでもないのに、150~140までの間で止まってしまいますね。 調べてみます。

hra1129 commented 7 months ago

原因が判明。IF文は関係なく、210 DIM DS$(IO) でも暴走します。 HEAP の FREE 処理の中で、まだ DIMされていない DS$() の変数領域を参照し、0x0000 が格納されているのに、それをポインタと見なし、値の再配置を実施しようとするのが原因。C3F3 あたりを破壊するので、状況によって暴走の仕方は異なります。

0x0000 チェックを追加して対応しました。

NasubiKT commented 7 months ago

最新版のmsx_bacon.exeとBACONLDR.BINをダウンロードして確認しました。 サンプルコードを実行してみたところ、暴走しました。 多量の文字列が表示され、最終的にString too longエラーが表示されました。 150行目のREAD文が、200行目の"Start SUB Routine"を読み込んでいるように見えます。

hra1129 commented 7 months ago

昨日は、確かにめちゃくちゃな文字列が表示されるのを確認できたのですが、 ISSUE#7 の対応を終えて、改めて試してみると、問題が再現しなくなってしまいました。

image

今回の修正は、累乗部分しか弄っておらず、このサンプルコードは累乗を使っていないので、不可解です。 少し保留とさせて下さい。

NasubiKT commented 7 months ago

最新版で確認したところ、たしかにエラーを再現できませんでした。 ISSUEを発行しておいて大変恐縮ですが、CLOSEとするかはHRA!さんのご判断にお任せいたします。

hra1129 commented 7 months ago

VisualStudio のデバッグモードで確認して終わって、リリースビルドをやり忘れていた可能性もありますので、 再現しない、ということから一旦 close にしようと思います。 また同様の現象が再現しましたら、また新たな ISSUE で挙げていただいてOKです。