HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2010
1021
たつきちエラー発生時の情報格納先について15解決


たつきち

リンク

2010/10/21(Thu) 20:26:55|NO.35438

ソースに何らかの問題があってエラーを起こした場合、
通常はダイアログ警告のOKをクリックすると実行プログラムが強制終了しますが、
ある程度開発を進めるうちにプロセスがフリーズするようになりました。
理由も分からず、毎回強制終了させるのが手間なのでonerrorを使ったのですが
今度はエラー情報が出なくなってしまいました。
調べるうちに

wparam:エラー番号
lparam:エラー行

が入っていることは分かったのですが、複数ファイルをインクルードした
プロジェクトの際にどのファイルでエラーを起こしたのかが分かりません。

これを識別する方法、あるいはエラーを起こしてもフリーズを避ける方法をご存知の方、
是非情報を頂ければと思います。

よろしくお願いします。



この記事に返信する


ANTARES

リンク

2010/10/21(Thu) 23:38:53|NO.35446

 まず、onerrorでごまかそうなどとという考え方を改め、
きちんとフリーズの原因を突き止めて除去する必要があります。
その第1歩は何処でフリーズしているかを突き止めることです。
http://antares.cn/hsp/trap/index.html#illegal

 予期しないフリーズは、たいていwaitもawaitもない無限ループ
または時間のかかるループで起こります。
無限ループであること自体に問題がないのであれば、
waitかawaitを入れるだけで解消するはずですが、
本来無限ループであってはならない場所なら、
無限ループになっている原因を除去する必要があります。



たつきち

リンク

2010/10/22(Fri) 00:22:35|NO.35448

>ANTARES様

私の言葉が足りなかったのかもしれませんが
「エラーの原因が分からない」からonerrorでごまかしているのではなく
エラーが起きたときに「強制終了する」ものが
「フリーズする(落ちずに固まる)」ようになったので
onerrorをつかったら一応強制終了はしてくれた、という話になります。

理由が分からないのはエラーの原因ではなくエラー時に「フリーズ」する原因です。
フリーズと強制終了、意図して言葉を使い分けていますので誤解の無い様お願いします。

ちなみに以下の例はrepeat〜loopの中でエラーが起きますが特にフリーズはしません。
よってループ内でエラーを起こすことが原因では無い様なのですが…。
repeat
mes stfr("%d",) loop



GENKI

リンク

2010/10/22(Fri) 00:52:11|NO.35449

> 複数ファイルをインクルードした
> プロジェクトの際にどのファイルでエラーを起こしたのかが分かりません。

エラー箇所が分からないことにはどうしようもありません。
エラー箇所を探しましょう。dialogやtitle、デバッグウィンドウ。方法は色々ありますよね。

でもとりあえずたくさんインクルードしているなら、デバッグ用に全部1個のファイルにまとめたものを作ってしまえばいいのではないでしょうか?
includeはファイルをその行に挿入しているだけなので難しいことはないと思います。



通りすがり

リンク

2010/10/22(Fri) 01:13:55|NO.35450

その例でエラー強制終了になり別の所でフリーズになるなら、
エラーかフリーズに分岐する何らかの原因があるわけですよね。
その場所を特定し、その原因を見極めろって話だと思いますが。

エラーかフリーズかが本当にランダムならメモリ破壊か、
その可能性を否定できればHSPまたはDLL等自体が壊れてる可能性が出てくるんでしょうが、
たぶんフリーズは特定の条件=何らかのバグで起こるべくして起きてるんでしょう。
場所が特定できていて、その上で原因が掴めないなら、その部分のソースを提示して意見を求めればいいのでは。

エラー場所特定の手段が分からないなら、
まずは地道にdialogを数行ごとに置いては消しして。フリーズの直前まで試す。
そのうちそれが面倒になってきたら、もっと楽に探せる別の方法を考えたら良いかと。



たつきち

リンク

2010/10/22(Fri) 10:17:08|NO.35451

ご意見を参考に原因が絞り込めました。
拡張プラグイン[hspogg]でdmminiを行った後エラー終了すると
本来終了時に自動で呼ばれるはずのdmmbyeが呼ばれず、
結果としてウィンドウが落ちずにフリーズしてしまうようです。

#include "hspogg.as" dmmini mes stfr("%d",) stop
実際、エラー原因の前にdmmbyeを手動で呼んでやればフリーズはしませんでした。
しかしdmmbyeはサウンド機能の終了なので、バグが起きるであろうプログラムの途中で
予め呼んでおくわけにも行かず、結果としてonerrorで呼んでやる以外に方法が思い当たりません。
そうなると最初のとおり、デバッグ情報が見られず困る――という話に戻ってしまいます。

dmminiを使った上でエラーが起きた際に通常のエラー報告が確認でき
更にフリーズせずに落ちるようにする方法

これについて何かご意見を頂ければと思います。



ORZ

リンク

2010/10/22(Fri) 13:15:49|NO.35452

エラーが出ないように作ろう。といってもそれはエラーを正しく検知できて初めてできること。
onerrorでどのファイルがエラーを起こしてるか分からない現状は難しいのでは。



SYAM

リンク

2010/10/22(Fri) 14:36:55|NO.35453

hspoggとエラーが関係ないのであれば、
hspoggをはずした状態でエラーをできるだけ無くして
hspoggを最後に有効化する のではダメかな?



たつきち

リンク

2010/10/22(Fri) 21:03:39|NO.35465

>ORZ様
申し訳ありませんが問題が根本的に伝わっていないようです。

>SYAM様
現段階では貴殿の意見が最も現実的かと思います。
今のところhspoggの機能はサウンドしか利用していないので、
音なしの状態で開発し完成したら音もつける、ということになりますね。


話が迷走気味ですので改めて整理させて頂きます。

現在私が質問させて頂いているのは以下の2点です。
そもそもエラーを起こさないように、といった話は論点が違いますので悪しからず。

●エラーを起こしたファイルが何であるかを格納しているシステム値はあるのか
 (wparam:エラー番号 lparam:エラー行数 なのでファイル名もどこかに?)
●hspoggのdmminiを使った状態でエラーが発生すると通常呼ばれるはずのdmmbyeが
 呼ばれずに固まる。これを回避する手段はあるのか



info

リンク

2010/10/22(Fri) 23:35:55|NO.35468

標準定義マクロの


__file__

に現在解析されているファイル名が入ります。
詳しくは ヘルプの __file__ の欄を見てください。


#include "hspogg.as" onerror goto *error dmmini mes stfr("%d",) stop *error dialog strf("エラーが発生しました\nファイル名 = %s\nErrNo = %d\nline = %d",__file__ , wparam , lparam ) // dmmbye end



たつきち

リンク

2010/10/23(Sat) 01:12:17|NO.35470

>info様
まさに知りたかった情報です。
ありがとうございました。

これにて解決とさせていただきます。



ANTARES

リンク

2010/10/23(Sat) 01:26:33|NO.35471

>理由が分からないのはエラーの原因ではなくエラー時に「フリーズ」する原因です。
 ということは、エラーの原因はわかっているのですか?
だとしたら、まず、それを書いてほしいですね。

>しかしdmmbyeはサウンド機能の終了なので、バグが起きるであろうプログラムの
>途中で予め呼んでおくわけにも行かず、結果としてonerrorで呼んでやる以外に
>方法が思い当たりません。
 バグを放置して動かす方法を教えてくれと言われても……。
そんな便利な方法があったらこちらが教えてほしいです。

>そうなると最初のとおり、デバッグ情報が見られず困る
>――という話に戻ってしまいます。
 バグを放置したいのに、なぜデバッグ情報が必要なのでしょう?

>●エラーを起こしたファイルが何であるかを格納しているシステム値はあるのか
> (wparam:エラー番号 lparam:エラー行数 なのでファイル名もどこかに?)
 たぶん、ないと思います。
通常、そういう情報がほしい場合はログを出力します。

>●hspoggのdmminiを使った状態でエラーが発生すると通常呼ばれるはずのdmmbyeが
> 呼ばれずに固まる。これを回避する手段はあるのか
 onerrorでとんだ先でdmmbyeを実行するのではダメなのですか?

>__file__に現在解析されているファイル名が入ります。
 onerrorでとんだ先で__FILE__を表示してもその部分のファイル名が
表示されるだけで、実行してみるまでもありません。
 __FILE__を使うなら、すべてのソースファイル切り替わりの
先頭に「errsrcfile=__FILE__」とでも書き、errsrcfileを表示することが必要です。
 本質的にはログ出力と同じですし、
http://antares.cn/hsp/trap/index.html#illegal
とも同じです。



GENKI

リンク

2010/10/23(Sat) 11:28:07|NO.35475

たつきちさんの文章は落ち着いてて凄く丁寧なのになぜか分かりにくい。
なのでたつきちさんの発言内容を少し整理。今更ですが。

・現在ソフトを開発中である。
・dmminiを使っている場合、何らかのエラーが発生するとフリーズする。(エラー内容はhgimg3に関係あるなしにかかわらない。)
・フリーズを回避するためにはonerror先でdmmbyeする必要がある。
・onerrorするとエラーが発生したファイル名が分からないため、デバッグが困難である。
・onerrorはエラーが発生したファイル名を取得できないため、開発中に使用するとエラー箇所の特定が困難。

という現状だったようです。現状説明って大事ですね。


>>infoさん(NO.35468)、ANTARESさん(NO.35471)

なるほど、そんな手が。
早速書いてみました。

main.hsp

errsrcfile=__FILE__ onerror *l_err ; エラー発生 gosub *test : errsrcfile=__FILE__ ;mes stfr("%d",) ;test1 : errsrcfile=__FILE__ stop ;エラー処理 *l_err dialog "#Error " + wparam + " in line " + lparam + " (" + errsrcfile + ")", 1, "HSPエラー" end #include "test.hsp"

test.hsp

#module #deffunc test1 errsrcfile@ = __FILE__ mes stfr("%d",) ;エラー発生 return #global *test errsrcfile=__FILE__ mes stfr("%d",) ;エラー発生 return

ものすごく面倒くさいですね。orz
やっぱり開発中にはonerrorは使わず、最後に実装したほうがよさそう。



たつきち

リンク

2010/10/24(Sun) 11:54:19|NO.35485

>GENKI様
まったくもってそのとおりです。整理いただきありがとうございます。
現状説明が不足していた為、誤解を招きました事を改めて皆さんにお詫びします。
以後利用させて頂く際は一層明快な文章を心がけます。

>ANTERS様
早合点してしまいましたが仰るとおりonerrorを呼んだファイル名が入るだけでした。
やはり移動の都度格納するのはあまり現実的ではないですよね。
皆さんの仰るとおり、開発中はサウンド機能をきるしかないかもしれません。



info

リンク

2010/10/28(Thu) 22:22:05|NO.35514

 すみません、自分も早とちりでした。
 お騒がせしました。



ANTARES

リンク

2010/10/29(Fri) 06:57:18|NO.35523

 エラーの原因にかかわらずフリーズするという話だったのですね。
ようやく理解できました(^_^;;
フリーズを再現できなかったので未確認ですが、
こんなのはどうでしょう?

*l_err dmmbye onerror 0
 「onerror 0」は、トラップしたいエラーとは別のエラーが起きた場合に
通常のエラー処理に戻す場合に使います。



ONION software Copyright 1997-2021(c) All rights reserved.