｢CardWirthPyは動作を停止しました｣
Issue #383
on hold
1.0beta2リリースお疲れ様です、七篠です。
表題のとおりフリーズするバグがあります。
このたびエラー時の｢問題の詳細｣の回収に成功したので報告いたします。
(ホントはリリース前に報告出したかったんですがスイマセン(汗))
問題確認したバージョン：1.0bta1および2
(記憶が確かならそれ以前のものでも発生していたかと)
発生頻度：シナリオ開始の際にランダムで(自分とこだと多分打率1割前後、
発生するシナリオに規則性なし)
(F9終了した後、ブックマークからシナリオを開始すると発生率がアップ？)
症状：宿画面からメニュー札消えた後、画面が変化せずフリーズ。
その他：エラーログ(CardWirthPy.exe.log)のようなファイルが出てこないので
これで解決できるかどうかわかりませんが、一応報告してみます。
｢問題の詳細｣の内容は常に以下のとおりでした：
問題の署名:
問題イベント名: APPCRASH
アプリケーション名: CardWirthPy.exe
アプリケーションのバージョン: 1.0.0.0
アプリケーションのタイムスタンプ: 49180193
障害モジュールの名前: StackHash_0a9e
障害モジュールのバージョン: 0.0.0.0
障害モジュールのタイムスタンプ: 00000000
例外コード: c0000005
例外オフセット: 1e0ba7f0
OS バージョン: 6.1.7601.2.1.0.256.1
ロケール ID: 1041
追加情報 1: 0a9e
追加情報 2: 0a9e372d3b4ad19135b953a78882e789
追加情報 3: 0a9e
追加情報 4: 0a9e372d3b4ad19135b953a78882e789
Comments (38)
-
repo owner
-
reporter
- attached Settings.xml
類似の事例ないか念のため確認してたら返事はやっ！(挨拶
ん～、サウンドフォントをむしろ使いまくっているというか(汗
えーと、七篠環境でのSettings.xmlです。
こんな感じでよろしいでしょうか......？ -
repo owner
ありがとうございます。そうなると、既知の問題では無さそうです。
どこで落ちているのか正確に知りたいので、専用のテスト版を作成しました。
お手数をおかけして大変申し訳無いのですが、以下のバージョンを使って問題を発生させ、その結果を教えていただけないでしょうか。
このバージョンを使ってシナリオを開くと、(ちゃんと動けば)
OnSCENARIOSELECT.logとset_scenario.logという2つのログファイルができます。ファイルの内容はシナリオを開くたびに更新されます。知りたいのは、問題が発生してハングアップした時に、ログがどこまで出力されているかです。一連のログが途中で止まっていれば、そこが問題の存在する箇所だと特定できます。ただ、毎回異なる場所で落ちるという可能性も無くはないので、できれば2回以上問題を発生させてみていただけるとありがたいです。
-
reporter
- attached logset01.zip
ほいさっさ、まずは一回目です。
-
reporter
- attached logset02.zip
シナリオとパーティーを変えて2回目も。
-
reporter
- attached logset03.zip
デバグモード解除してまたパーティー変えた3回目。
-
reporter
- attached logset04.zip
4回目であります。ブックマーク外からも再現したいけど
手間がかかるせいかいまだ追跡できず。 -
reporter
- attached logset05.zip
ブックマーク外フリーズキタコレ！
-
repo owner
ありがとうございます。シナリオを読み込む側のスレッドのログがまったく出ていませんね。そんなはずはないのでなぜなのかと思ったのですが、たぶんログがバッファリングされていてファイルに書き出される前にアプリケーションが落ちてしまっていたのでしょう。
確実にファイルに書き出されるようにしてみました。このバージョンで試していただけないでしょうか。
-
reporter
- attached logset06.zip
ういっす、こんどは
set_scenario.logも3行ほど出力されましたです。 -
repo owner
ありがとうございます。以前XP環境で設定ダイアログの終了とスキンを変更する処理が同時に走るとハングアップするバグ(おそらくwxPythonのバグ)に対処したことがあるのですが、それと似た感じがします。同じやり方で対処できるかもしれません。
同じ用法が通用するなら、以下のバージョンで問題は起きなくなる(か、非常に稀になる)はずです。試していただけないでしょうか。
-
reporter
...む、設定を変更(デバグモード解除)して
念のため宿出て終了させようと思ったら、
CWPyの窓消えた後になにかでてきた。そういえばたまに｢閉じる｣ボタンクリックした後にこういうの出てきてたけど.....
終了した後の挙動なんであまり実害ないし、なんとなくコッチは別件後回しかも。
問題の署名:
問題イベント名: APPCRASH
アプリケーション名: CardWirthPy.exe
アプリケーションのバージョン: 1.0.0.0
アプリケーションのタイムスタンプ: 49180193
障害モジュールの名前: bassmidi.dll
障害モジュールのバージョン: 2.4.9.0
障害モジュールのタイムスタンプ: 54807e9c
例外コード: c0000005
例外オフセット: 000015bd
OS バージョン: 6.1.7601.2.1.0.256.1
ロケール ID: 1041
追加情報 1: 0a9e
追加情報 2: 0a9e372d3b4ad19135b953a78882e789
追加情報 3: 0a9e
追加情報 4: 0a9e372d3b4ad19135b953a78882e789 -
reporter
っと、もうアップデート来てた。 wxなんちゃらですか、
#92あたりでナニカミオボエガがが...... -
reporter
- attached logset07.zip
おお、治ったぽいです。
とりあえず、0x100回ほど
｢エンターキーで張り紙見てエンターで開始してF9にエンターで避難して～｣を
繰り返してみましたがフリーズ起きてません。 -
repo owner
ありがとうございます。どうやら設定ダイアログの問題の仲間のようです(おそらく
#92とは別の原因です)。この問題はライブラリ側にあってCWPy側では直せないので、直したというより回避したという感じになります。後はログを出力しないバージョンで問題が再発しなければ大丈夫のはずです。最後までお手数をおかけしてしまいますが、下記のバージョンをお試しください。
-
reporter
- attached logset08.zip
再発。嗚呼なおったとおもったのに。
これが噂の｢一寸のBugにもゴブの魂か｣......
問題の署名:
問題イベント名: APPCRASH
アプリケーション名: CardWirthPy.exe
アプリケーションのバージョン: 1.0.0.0
アプリケーションのタイムスタンプ: 49180193
障害モジュールの名前: StackHash_0a9e
障害モジュールのバージョン: 0.0.0.0
障害モジュールのタイムスタンプ: 00000000
例外コード: c0000005
例外オフセット: 1e039dc7
OS バージョン: 6.1.7601.2.1.0.256.1
ロケール ID: 1041
追加情報 1: 0a9e
追加情報 2: 0a9e372d3b4ad19135b953a78882e789
追加情報 3: 0a9e
追加情報 4: 0a9e372d3b4ad19135b953a78882e789 -
repo owner
回避処理が甘かったかもしれません。もう少し強くしてみました。これならどうでしょうか。
-
reporter
Oh,嫌eah!
.......20160603dでも発生ですorz
問題の署名:
問題イベント名: APPCRASH
アプリケーション名: CardWirthPy.exe
アプリケーションのバージョン: 1.0.0.0
アプリケーションのタイムスタンプ: 49180193
障害モジュールの名前: StackHash_0a9e
障害モジュールのバージョン: 0.0.0.0
障害モジュールのタイムスタンプ: 00000000
例外コード: c0000005
例外オフセット: 1e0ce6f6
OS バージョン: 6.1.7601.2.1.0.256.1
ロケール ID: 1041
追加情報 1: 0a9e
追加情報 2: 0a9e372d3b4ad19135b953a78882e789
追加情報 3: 0a9e
追加情報 4: 0a9e372d3b4ad19135b953a78882e789 -
reporter
ん、20160603eフリーズげｔ。
今度は運よく(?)すぐキました。
もういっかいやってみます。
問題の署名:
問題イベント名: APPCRASH
アプリケーション名: CardWirthPy.exe
アプリケーションのバージョン: 1.0.0.0
アプリケーションのタイムスタンプ: 49180193
障害モジュールの名前: StackHash_0a9e
障害モジュールのバージョン: 0.0.0.0
障害モジュールのタイムスタンプ: 00000000
例外コード: c0000005
例外オフセット: 1e10c0c4
OS バージョン: 6.1.7601.2.1.0.256.1
ロケール ID: 1041
追加情報 1: 0a9e
追加情報 2: 0a9e372d3b4ad19135b953a78882e789
追加情報 3: 0a9e
追加情報 4: 0a9e372d3b4ad19135b953a78882e789 -
repo owner
発生頻度は下がっている感じでしょうか？
ちょっとどうやったら完全に回避できるか見当もつかなくなってきました。アプローチを少し変えてみます。次のバージョンはどうでしょうか。
-
reporter
直感に従えば、20160603cで
同パーティーで延々同じシナリオに入り続けて、いったんフリーズが出なくなったんです。これに気をよくして、折角だからよそのパーティーでも.....と、
｢冒険の再開｣で別のパーティーに交代しながら、
ブックマークのシナリオを実行してみたところ、再発、という..... -
reporter
むぅ、やはり再発。ハテさて再現の確率がわからぬ......
しかし、シナリオの相性ってあるんでしょうか？フリーズしやすいとかしにくいとか......
どうも直感に従うと、自分のシナリオで妙にエラーが多発してる悪寒ががが。
問題の署名:
問題イベント名: APPCRASH
アプリケーション名: CardWirthPy.exe
アプリケーションのバージョン: 1.0.0.0
アプリケーションのタイムスタンプ: 49180193
障害モジュールの名前: StackHash_0a9e
障害モジュールのバージョン: 0.0.0.0
障害モジュールのタイムスタンプ: 00000000
例外コード: c0000005
例外オフセット: 1e10c0c4
OS バージョン: 6.1.7601.2.1.0.256.1
ロケール ID: 1041
追加情報 1: 0a9e
追加情報 2: 0a9e372d3b4ad19135b953a78882e789
追加情報 3: 0a9e
追加情報 4: 0a9e372d3b4ad19135b953a78882e789 -
repo owner
うーん、分かりません。問題はシナリオ選択ダイアログだけで発生するのでしょうか。パーティの切替後に発生したという事ですが、そうした他のダイアログを操作した後に発生するという事はないでしょうか。
-
reporter
あ、わかりにくい説明でスミマセン(汗
フリーズは常にシナリオの開始時に発生しています。
すなわち、シナリオをフリーズなく開始できたら、即シナリオを終了して宿に戻り、
別のパーティーに切り替えて、また問題なくシナリオを開始できれば、
またシナリオ終了して、さらに別のパーティー、という格好です。
今のところ、最大で5パーティーくらい連続でシナリオ開始に成功してる感じです。
確実に発生しない(おきたり起きなかったりする)あたり、ややこしい現象ですが、
パーティー切り替えなどの別の操作で発生確率が上がっているのかもしれません。 -
repo owner
もう少しアプローチを変えてみました。これでどうでしょうか。
-
reporter
あ、珍しい。稀に、シナリオ開始の際の｢読み込み失敗｣が出てくるんですが、 ........実はディスクドライブが大穴だったりするのでしょうか(汗
SSDじゃなくてHDDにうつして検証したほうがいいのかな。
｢[Window Title]
エラーメッセージ[Content]
シナリオの読み込みに失敗しました。[閉じる]｣
-
reporter
....っと、20160603h、いってみます。念のためSSDとHDD両方かくにんやってきます。
-
reporter
おや、｢障害モジュールの名前: ntdll.dll｣？
いやHDDにうつしたものもSSDのほうも両方フリーズする。
.........でもオフセットの項目が何か違う......
HDD
問題の署名:
問題イベント名: APPCRASH
アプリケーション名: CardWirthPy.exe
アプリケーションのバージョン: 1.0.0.0
アプリケーションのタイムスタンプ: 49180193
障害モジュールの名前: ntdll.dll
障害モジュールのバージョン: 6.1.7601.23418
障害モジュールのタイムスタンプ: 5708a73e
例外コード: c0000005
例外オフセット: 0002e43e
OS バージョン: 6.1.7601.2.1.0.256.1
ロケール ID: 1041
追加情報 1: 0a9e
追加情報 2: 0a9e372d3b4ad19135b953a78882e789
追加情報 3: 0a9e
追加情報 4: 0a9e372d3b4ad19135b953a78882e789
SSD
問題の署名:
問題イベント名: APPCRASH
アプリケーション名: CardWirthPy.exe
アプリケーションのバージョン: 1.0.0.0
アプリケーションのタイムスタンプ: 49180193
障害モジュールの名前: ntdll.dll
障害モジュールのバージョン: 6.1.7601.23418
障害モジュールのタイムスタンプ: 5708a73e
例外コード: c0000005
例外オフセット: 0002e4a6
OS バージョン: 6.1.7601.2.1.0.256.1
ロケール ID: 1041
追加情報 1: 0a9e
追加情報 2: 0a9e372d3b4ad19135b953a78882e789
追加情報 3: 0a9e
追加情報 4: 0a9e372d3b4ad19135b953a78882e789 -
repo owner
ちょっとまた見当がつかなくなってきたので、とりあえずログ出力を復活させてみました。どこまでログが出るか見ていただけないでしょうか。
-
repo owner
ところでOSのバージョンを見るとWin7なのではないかと思うのですが、32ビットバージョンと64ビットバージョンのどちらでしょうか。
-
reporter
あ、Windows7の64bit版であります。
-
reporter
- attached logset09.zip
やどのパーティー51チーム一周してようやくHit........
ううむ、もうとりあえずおひらきにすべきなのだろうか......直感としてはかなり改善された気もしますし、これ以上を求めるとなると
PyQtだかPyGTKだかもうまったくべつのナニカをやらかす必要があるのでしょうね.....
問題の署名:
問題イベント名: APPCRASH
アプリケーション名: CardWirthPy.exe
アプリケーションのバージョン: 1.0.0.0
アプリケーションのタイムスタンプ: 49180193
障害モジュールの名前: StackHash_0a9e
障害モジュールのバージョン: 0.0.0.0
障害モジュールのタイムスタンプ: 00000000
例外コード: c0000005
例外オフセット: 1e0ce6f6
OS バージョン: 6.1.7601.2.1.0.256.1
ロケール ID: 1041
追加情報 1: 0a9e
追加情報 2: 0a9e372d3b4ad19135b953a78882e789
追加情報 3: 0a9e
追加情報 4: 0a9e372d3b4ad19135b953a78882e789 -
repo owner
この問題に取り組んできての経験則ですが、これはおそらくダイアログオブジェクトの破棄とファイルの読込が同じようなタイミングで発生した時に起こるもののようです。そのためダイアログの破棄を遅らせてファイルの読込の無いタイミングを見計らえばよいのですが、そのタイミングの取り方が非常に難しいです。
これまでの版ではシナリオの最初のエリアに移動した時点(最初のエリアの読込が終わった時点)で破棄する、という風に処理するようにしたのですが、発生率は下がったものの、それでは充分ではないようでした。どうもシナリオ開始直後にまた別のエリアに移動するなどのシナリオで問題が起きていそうです。これはさらなるエリアデータの読込が発生しているためだと思われます。
以下のバージョンは、その辺のタイミングをもっと後に回して、シナリオ開始時イベントが完全に終わった時点でダイアログを破棄するようにしたものです。このバージョンならもしかするとかなりの確率で問題を回避できるかもしれません。
不思議なのは、他の方の環境でこうした現象が起きていると聞いた事が無いことです。Win7の64ビットというのはかなり一般的な環境です。何か常駐ソフトとの競合などが発生しているのかもしれません(例えばcwxeditorはVirtualMIDISynthというソフトと競合してトラブルを抱え込んだことがあります)。
もしそうである場合、常駐ソフトを1つずつ切っていくなどして試すと、問題の所在が明らかになるかもしれません。
また、初期設定で動かしてみると実は問題が起きない、つまり実はどれかの設定と環境の兼ね合いで問題が起きていた、というような事も考えられないではないです。ただ、私がそちらの設定を使って試してみたところでは問題は再現しませんでした。
ついでにこれも経験則ですが、GUIツールキットは巨大なライブラリなので、何を使ってもだいたいトラブルにぶつかるみたいです。私はMicrosoftやその他大手企業のライブラリで2～3度バグを踏んづけた事があります。
-
reporter
ねおち してましたorz
あはぁ、｢シナリオ開始直後にまた別のエリアに移動｣ですか.......
云われてみればフリーズ発生の状況が、
途中から｢宿のメニュー札が消えてすぐ｣でははく
｢宿のメニュー札と、AdventurersInn.png消えてすぐ｣に変化していました。
ご指摘のとおり、拙作MoneyUtilityは
開始エリアからすぐ別のエリアに飛ぶ構造をしています。
シナリオ構造がからんで｢フリーズしやすいシナリオ/そうでないシナリオ｣という
相性のようなものがおきていたとすれば、直感とよく一致しそうです。
.....なんか自分とこのシナリオのせいでご迷惑おかけしてるみたいでスイマセン(汗
問題が環境依存で発生していないか、という懸念はたしかにありました。
自分とこのコンピュータ、色々アレすぎるのでorz
｢ディスプレイが半ダースつながってる｣
｢SSDのRAID環境｣
｢外付けオーディオデバイス利用(あまつさえIEEE1394b接続なるキワモノ)｣
ええもちろん茶箱に入ったグラサン男のパーツはオトモダチです
.....なんか自分とこの環境のせいでご迷惑おかけしてるみたいでスイマセン(大汗
｢何を使ってもだいたいトラブルにぶつかる｣ものですか......
隣の芝生が青く見えても、無くて七癖、というやつですかね。
いえ全力で癖だらけの環境と使い方やってる自分が
言えた義理ではないかも知れませんが
重ね重ね自分とこのせいでご迷惑おかけしてるみたいでまじスイマセン(滝汗 -
reporter
- changed status to on hold
(ぁ、多分コッチの発生率かなり下がってきてるぽいので、サウンドフォントの件お先にどうぞ......)
-
repo owner
特殊な環境はどうしてもテストケースが不足しがちなので助かります。その手のバグは、本当の虫ではないですが、1人踏んだものはそのうち30人が踏むものと考える事にしています。
といっても今回の問題、HDDでもSSDでも出るところを見ると副記憶装置のドライバでは無さそうですし、症状からすると音声もグラフィックも関係無さそうです。メインメモリでしょうか？ そんなわけが無い気もするのですが……。やはりソフトウェア側の環境が怪しい気もします。
最後に行った対処で問題は発生しなくなったでしょうか。ほぼ回避できているようであれば、その対処をマージして解決としたいと考えています。最終的にはライブラリのアップデートで完全に解決するでしょう。
-
reporter
この｢シナリオ開始時のフリーズ｣が発生するメカニズムは、
自分のつたない理解力で把握する限りですと、
(ＣＷＨＳチャット向けに使った表現のリサイクルですが；)・Pyエンジンの裏方というか黒子さんに
｢シナリオ選択ウィンドウのあとしまつ｣と｢シナリオファイルの読み込み｣を
同時にぶつけちゃう状況が起きてるせいで(フリーズするので)はないか・なのでオーダー出すタイミングをうまく調整してやることで問題を回避できないか
ということなのだろうと理解しています。
そこで、シナリオの開始エリアから複数のエリアを次々たらいまわしにするような
(つまり連続でファイルを読みに行かせる)検証シナリオを作ることを考えていた次第です。自分の理解があっていれば、の話なので難ですが、
(あっていれば)この検証シナリオで確認して解決といえそうですし、
(休みなのにむしろ所用重なっていて検証不十分なのですが；)
今のところは自シナリオの出入りで問題らしい問題は見つかっていないので、
ひとまず現状の対応のマージでも、(あくまで個人的な直感ですが、)
8割がた問題はないという気がします。とまれ、個人的な環境の事情に特殊なシナリオのあわせ技みたいなバグで
色々ご対応いただき感謝しております。
出来れば｢解決｣以降の再発がないことを祈りたいのですが(汗
万一再発があった場合は、再びここにレスする形でよろしいでしょうか、
それとも、改めて課題を起こしたほうがよいのでしょうか？ -
repo owner
黒子は二人いるので本来ならば同時に仕事しても問題はないはずなのですが、おそらくライブラリの内部のどこかでメモリアクセス違反を起こして超常現象が起きているのでしょう(Windowsの例外コード0xc0000005はメモリアクセス違反エラーです)。
最新の対処では、プレイヤーが操作可能になった時点でダイアログを破棄するようにしているので、たらい回しにされている間は破棄されません。おそらく同じ問題は発生しないと思います。それでもバグは予測がつかないものなので、試していただけるとしたらありがたいことです。
検証にお付き合いいただきありがとうございます。問題の軽減には成功しているらしいので、とりあえず今のバージョンでマージして様子を見ましょう(pull request #1482)。
- Log in to comment
ご迷惑をお掛けして申し訳ありません。
この手のエラーは、サウンドフォントをまったく使用していない時に時折発生する事が分かっています。サウンドフォントを指定しなかった時に使用するライブラリの音声再生機能にバグがあるためです。
音声周りの設定がどのようになっているか教えていただけないでしょうか。