バグ:音声再生で再生位置表示スレッド(とセマフォハンドル)が解放されないまま次の再生がはじまる

Issue #345 resolved

ルンバ created an issue 2020-04-17

Build: 2020-04-12 13:30:02 Release (64-bit)
Compiled by Digital Mars D 2091

Win10　でメッセージコンテントをいじっていたら（OKボタンクリック時？）通常のエラーログとは異なる別窓で以下のコピー内容が出てきて強制終了しました。最近（ここ半月ぐらい？）このような別窓でのエラー出力が出て強制停止する事が数回ありました。ログらしきものを見てもｘエディタとの関連は不明なので私の環境依存かと思ったのですが、このウインドウがタスクバー上ではｘエディタの位置に所属していたので報告する事にします。（以前の停止時の作業内容は覚えていません）

∇ ｳｨﾝﾄﾞｳﾀｲﾄﾙ ∇
core.exception.AssertError

∇ ｽﾀﾃｨｯｸﾃｷｽﾄ ∇
OK
core.exception.AssertError@base\src\java\nonstandard\sync\condition.d(113): Unable to destroy condition

0x00007FF6DD5829E3
0x00007FF6DD5F8486
0x00007FF6DD587A88
0x00007FF6DD56CF41
0x00007FF6DD4FF627
0x00007FF6DD497F79
0x00007FF6DD587A88
0x00007FF6DD56CF41
0x00007FF6DD498077
0x00007FF6DD44CE77
0x00007FF6DD3BBA59
0x00007FF6DD3BA018
0x00007FF6DD3BA372
0x00007FF6DD44555C
0x00007FF6DCD9F77F
0x00007FF6DC1F3515
0x00007FF6DD58C693
0x00007FF6DD58C51C
0x00007FF6DD58C5FB
0x00007FF6DD58C51C
0x00007FF6DD58C463
0x00007FF6DD574F10
0x00007FF6DC1F3644
0x00007FF6DD609960
0x00007FFF45867BD4 in BaseThreadInitThunk
0x00007FFF45F0CE51 in RtlUserThreadStart

∇ ｳｨﾝﾄﾞｳﾀｲﾄﾙ ∇
core.exception.AssertError

∇ ｽﾀﾃｨｯｸﾃｷｽﾄ ∇
OK
core.exception.AssertError@base\src\java\nonstandard\sync\condition.d(113): Unable to destroy condition

‌

ここより以下は以前に同じようなのが出た時のものです

‌

∇ ｳｨﾝﾄﾞｳﾀｲﾄﾙ ∇
core.exception.AssertError

∇ ｽﾀﾃｨｯｸﾃｷｽﾄ ∇
OK
core.exception.AssertError@base\src\java\nonstandard\sync\condition.d(113): Unable to destroy condition

0x00007FF678F8FCA3
0x00007FF6790850D6
0x00007FF678FC2208
0x00007FF678F8FE11
0x00007FF678EF7687
0x00007FF678E5F6D9
0x00007FF678FC2208
0x00007FF678F8FE11
0x00007FF678E5F7F7
0x00007FF678DF1CA7
0x00007FF678D38959
0x00007FF678D36868
0x00007FF678D36C82
0x00007FF678DE7DCC
0x00007FF67844FB38
0x00007FF67715B496
0x00007FF678FCC463
0x00007FF678FCC29C
0x00007FF678FCC39B
0x00007FF678FCC29C
0x00007FF678FCC0D3
0x00007FF678F9F510
0x00007FF67715BAF2
0x00007FF6790DEFE4
0x00007FFDAD0F7BD4 in BaseThreadInitThunk
0x00007FFDAD4CCED1 in RtlUserThreadStart

∇ ｳｨﾝﾄﾞｳﾀｲﾄﾙ ∇
core.exception.AssertError

∇ ｽﾀﾃｨｯｸﾃｷｽﾄ ∇
OK
core.exception.AssertError@base\src\java\nonstandard\sync\condition.d(113): Unable to destroy condition

Comments (16)

k4nagatsuki repo owner
ご報告ありがとうございます。

GUIツールキット内の非同期処理でエラーが起きている(Conditionが二重開放されている？)ようなのですが、なぜそういう事が起きているのかちょっとよく分かりません。

最新の事例は64-bitのリリース版で起きているようですが、デバッグ版でも発生するでしょうか。
- 2020-04-17T14:11:08+00:00
ルンバ reporter
下の方はデバッグ版でしたがバージョンを控えておりませんでした…

今後はこの手のメッセージも全て報告いたします。

また、報告の最新事例の後でエディタ再起動後、シーンビューの背景セルを複数選択するとシナリオ問わず確実にエディタがフリーズするようになりました。しかし、これはPCを再起動してみたら正常化しました。

関係あるかわかりませんが、BGMコンテンツで色々な曲を試聴した後に、そのエリアやパッケージのイベントツリーが非表示になる現象は最新リリース版含め、たまにでます。またやはりセーブをするとそのまま強制停止になる事も時々あります。
- 2020-04-17T14:20:26+00:00
k4nagatsuki repo owner
もしかしてBGMを流しっぱなしにして作業等されているでしょうか？その場合、非同期処理がかなりの頻度で発生するはずです。
- 2020-04-17T14:24:11+00:00
ルンバ reporter
CWエンジンを起動してテストプレイしながらの作業なので大体CWのBGMが流れっぱなしですが、他に動画や音楽などを流しっぱなしというのは無いです。とりあえず最新エディタに乗り換えコンソール版で作業していきます。
- 2020-04-17T14:26:58+00:00
k4nagatsuki repo owner
私が当初想像した原因では、エラー箇所はcondition.d(113)ではなくcondition.d(111)になるはずなので、どうも違うようです。そうなるとエラーが発生するコードパスが論理的に存在しなくなってしまいます。

残るはCloseHandleの戻り値がおかしいケースなのですが、それはWindows APIにバグがある≒OSにバグがあるという事になるので、正直なところ可能性としては考えにくいです。

しかし、過去実際にフォント関係のAPIにバグが発生していた事もあるので、確実に起こらないというわけでもありません。

OSのバージョンを教えていただけないでしょうか？

私の手持ちの環境はWindows 10 Pro(64-bit) 1903ですが、今の所一度もこの事象は発生していません。
- 2020-04-17T15:04:41+00:00
ルンバ reporter
Windows 10 Pro(64-bit) 1909　ですね
- 2020-04-17T15:15:10+00:00
k4nagatsuki repo owner
リリース版ではあるもののまだ自動配信されていないバージョンですね。

バージョンが違うとなれば、さらにOSを疑った方がよさそうです。

https://bitbucket.org/k4nagatsuki/cwxeditor-k4nagatsuki/downloads/cwxeditor_test_20200418a.zip

エラーが起きた時にエラーコードが表示されるように手を入れてみました。このバージョンで現象を発生させれば、もう少し詳しい情報が採れるかもしれません。
- 2020-04-17T15:28:32+00:00
ルンバ reporter
ご対応ありがとうございます。

ではcwxeditor_fnine_20200417_x64　にそれを上書きした物で作業してみます。

ちなみにBGMを流しっぱなしになるのが問題なのはエディタ内でBGMコンテンツで流しっぱなしという意味でしょうか？それとも他のアプリケーション含めPCでの全作業でのBGM再生重複が問題になりますか？
- 2020-04-17T16:10:45+00:00
k4nagatsuki repo owner
エディタ側です。再生位置の表示のために非同期処理を多用しています。
- 2020-04-17T16:13:45+00:00
ルンバ reporter
エディタ内だけだと、BGMコンテンツでの選曲中しか再生していませんし同時に複数という事は無いですね。
- 2020-04-17T16:23:11+00:00
ルンバ reporter
Build: 2020-05-26 22:40:07 Debug (64-bit)
Compiled by Digital Mars D 2092

BGMコンテンツで色々な曲を試聴した後に、そのエリアやパッケージのイベントツリーが非表示になり処理が重くなる現象はその後も継続しているのですが、そのような状態になって来たので一旦セーブして終了し、エディターを再起動したらその時点で別ウインドウで以下メッセージが出てその後エディターは異常停止（さらに再起動すれば以後正常動作）というパターンが二度あったので報告します。

∇ ｳｨﾝﾄﾞｳﾀｲﾄﾙ ∇
core.exception.AssertError

∇ ｽﾀﾃｨｯｸﾃｷｽﾄ ∇
OK
core.exception.AssertError@base\src\java\nonstandard\sync\condition.d(114): Unable to destroy condition: %s6

0x00007FF61E30DE33
0x00007FF61E3F9F7E
0x00007FF61E33F698
0x00007FF61E30E071
0x00007FF61E273D97
0x00007FF61E1DBE09
0x00007FF61E33F698
0x00007FF61E30E071
0x00007FF61E1DBF27
0x00007FF61E16E3D7
0x00007FF61E0B5029
0x00007FF61E0B2F38
0x00007FF61E0B3352
0x00007FF61E1644FC
0x00007FF61D7826C8
0x00007FF61C465A56
0x00007FF61E34A713
0x00007FF61E34A54C
0x00007FF61E34A64B
0x00007FF61E34A54C
0x00007FF61E34A383
0x00007FF61E31E7E0
0x00007FF61C4660B2
0x00007FF61E454154
0x00007FFAA3EB7BD4 in BaseThreadInitThunk
0x00007FFAA67ECE51 in RtlUserThreadStart

※以下同じ症状の二度目

∇ ｳｨﾝﾄﾞｳﾀｲﾄﾙ ∇
core.exception.AssertError

∇ ｽﾀﾃｨｯｸﾃｷｽﾄ ∇
OK
core.exception.AssertError@base\src\java\nonstandard\sync\condition.d(114): Unable to destroy condition: %s6

0x00007FF657F1F613
0x00007FF65800B75E
0x00007FF657F50E78
0x00007FF657F1F851
0x00007FF657E85577
0x00007FF657DED5E9
0x00007FF657F50E78
0x00007FF657F1F851
0x00007FF657DED707
0x00007FF657D7FBB7
0x00007FF657CC6809
0x00007FF657CC4718
0x00007FF657CC4B32
0x00007FF657D75CDC
0x00007FF657393718
0x00007FF656075CE6
0x00007FF657F5BEF3
0x00007FF657F5BD2C
0x00007FF657F5BE2B
0x00007FF657F5BD2C
0x00007FF657F5BB63
0x00007FF657F2FFC0
0x00007FF656076342
0x00007FF658065934
0x00007FFA187F7BD4 in BaseThreadInitThunk
0x00007FFA1AD0CE51 in RtlUserThreadStart
- 2020-05-28T12:41:52+00:00
ルンバ reporter
順番が前後しますが、初期設定や他シナリオ等で再現するか確認しますのでお待ち下さい。
- 2020-05-28T12:51:50+00:00
ルンバ reporter
初期設定xエディタで「遺跡に咲く花」開いた直後でタスクマネージャーでxエディタを見ながらテスト

CPU　0.1％　　メモリ　43.MB　電力消費　非常に低い　から開始して

単に[デフォルト]曲を一曲再生しているだけだとゆっくりCPU、メモリが上昇するが実害は無いレベルですが、
（しかし単にコンテンツ内での試聴をしているだけで、適用やOKを押してはいないのでヒストリーが増えているわけではない）

[デフォルト]曲を上から下まで次々クリックして再生を切り替えを繰り返し、のべ30曲くらい再生していくと、メモリ　CPU使用率　使用電力が　顕著に上昇しだし
CPU　10-20％　メモリは３桁MBに上がって　使用電力も「非常に高い」に上がり

あとは操作をやめ、そのまま放置してみているとさらにCPUは20％台をただよい　メモリはどんどん上がり続けます
メモリは1Gを越えさらに上がり続けますがその頃には、再操作の応答が非常に悪くなり応答なしが発生します。（なのでタスクマネージャー上からタスク終了しました）

このテストではエラーメッセージはでなかったですが、メモリは一旦上がりだすと際限なく上がるようで、また操作が重なる方がよりその傾向が加速されるようなので、普段多数の曲再生を繰り返して選曲している時の不具合の原因になっているようです。
- 2020-05-28T13:31:31+00:00
k4nagatsuki repo owner
pull request ~~#61~~

再現手順のおかげで起きている問題を特定できたと思います。

技術的な話になってしまいますが、おそらく音声再生で再生位置表示スレッド(とセマフォハンドル)が解放されないまま次の再生がはじまる事で、cwxeditorが確保可能なリソース量を食い潰してしまっているのでしょう。

この問題が実際に起きているか確認する手段としては以下の方法があります:
1. タスクマネージャを開き、「詳細」タブを選択します。
2. 一覧のヘッダ部分で右クリックすると「列の選択」が行えるので、「ハンドル」と「スレッド」を選択して一覧上に表示します。
3. cwxeditor上で問題の操作を行います。
ここで「ハンドル」と「スレッド」が増えたまま戻らなくなり、ある程度増えたところで現象が発生するようであれば、上述の問題であると確定できます(メモリ量もたぶん同じ問題だと思います)。

新しいテスト版を使い、同じ操作を行ってハンドルやスレッドが増えない(あるいは一時的に増えてもすぐ元に戻る)ようであれば、不具合の修正はできたと考えてよいはずです。

‌
- 2020-05-29T13:15:49+00:00
ルンバ reporter
- changed title to バグ:音声再生で再生位置表示スレッド(とセマフォハンドル)が解放されないまま次の再生がはじまる
- 2020-05-29T13:41:26+00:00
ルンバ reporter
- changed status to resolved
解決しました、ありがとうございます。最新版と前のバージョンを比較した所、おっしゃる通りの挙動の差がありました。タイトルは意味不明なので直しておきます。
- 2020-05-29T13:42:55+00:00
Log in to comment

Assignee: –

Type: bug

Priority: major

Status: resolved

Votes: 0

Watchers: 1