画像を上げておきました。私のところでも、同じ条件で毎回起きるわけでもないようで、??です。初回でも起きる場合があるし、何回も起きない場合があるし、ってまったく??です。再現しない場合もあって、やはりよく分かりません。<開発者>~~再現のためのレシピを忠実に何度も試したのですが、やはり私の環境では再現しませんでした。~少々厄介なことになってしまいました(苦笑)。(2)メモリやリソースなどの環境の問題~のどちらかだと思いますが、~私の経験では90%は(1)の方です。orz~~ただ、再現しないことには障害追跡ができません。言う現象が、やはりおきます。抽出データでの再現はうまくいってません。演奏してみると、正常に、「2.戦いの...」が表示されます。Museを再起動せずにこの抽出データを再生してみると.........やはり「1.ソロモンの...」のまま演奏が始まったりします。同様です(いや、正常ケースがなくなるかな。<開発者>~~もう一つ、実験してもらうことを思いついたので、試してもらえますか?~本来「2.戦いの...」が表示されなければならないのに「1....」のままになっている状態で、~Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。~次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。~これでも「1....」のままになっているか否かを試してみてください。SP3なので試してみました。<開発者>~~ご報告、ありがとうございます。~Museのバグである公算が高まってきたのは残念ですが、~再現する試験者が増えたのは心強い限りです。~お手数ですが、お手すきの時に以下の実験をして結果を教えてもらえますか?~=====~本来「2.戦いの...」が表示されなければならないのに「1....」のままになっている状態で、~Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。~次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。~これでも「1....」のままになっているか否かを試してみてください。どっちでも、「1.ソロモンの...」のままです。(2)次いで、文字列そのものを疑っていろいろやってみました。ないか」という推測に達しました。この3ついずれでも発生します。発生します(30バイトになります)。Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。これでも「1....」のままになっているか否かを試してみてください。ともに「1....」のままでした。起動直後の演奏では正常に切り替わることが多い気がします。Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。症状を確認しましたのでご連絡します。当該症状のにつきまして、同様の結果が出ました。変えた時のスクリーンショットとシステムのプロパティ画面です。SP3を動かした時では発生しませんでした。再現性は100%ではないですが,症状が出ていますので報告します。自分のデータで上記の条件で再現しないか調査中ですが未だに再現していません。いま少し調べてみます。Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。表示は更新されないままでした。気付いた点は以下の3点です。条件のとき、構文の直前からリロード再生を行うと発生するようです。以下のデータで、譜面モニタ上の最初の小節で何度か右クリックすると再現します。ファイルサイズが大きいだけではだめで、構文がある程度複雑でないと再現しないようです。条件を満たしただけで同じ現象が発生します。内部状態を変化させていることが示唆されます。発生することを確かめました。よって、この間の更新が現象の一因になっていることが示唆されます。orz~再現性は確保できているので、科学的にアプローチできます。~~今は、履歴データによって現象が出たり出なかったりする件を追っていました。~これもまた微妙な按配です。~ほんの少し履歴データを変更すると、途端に現象が出なくなります。~Museデータを、ちょっち変更すると出なくなるのと同じ印象です。~まるで、ガラス細工のようです(苦笑)。~~で、再現する状態でプログラムを少しずつ削り取っていって、~症状が出なくなる瞬間を把握しようと思って作業していたのですが、~結局、MuseWikiの(対処)の項に記載したのと同じ結果に行き着きました。~~テキストエリアに表示する文字列のメモリ確保を1バイト増やすか、~履歴データのパス文字列のメモリ確保を1バイト増やすか、~どちらか一方でも行うと症状は出なくなります。~~アライメントの関係かとも思い、~コンパイルの最適化オプションを外すなどもしてみたのですが、~結果は同じでした。OS依存の現象のようで、大変そうです(^_^;)が、お待ちしてます~現時点の対処方法(1バイト余分にメモリ確保)は、今一つ釈然としないのですが、~一応今まで追跡した内容からして、~限りになく患部に近い所に薬を塗れているのではないか、~と思い始めてきました。個人的にはとても原因が気になります。メッセージが発行されていないようです。いう結果になりました。問題はリロード時に生じているのではないかというのが、私の推測です。メッセージが発行されていないようです。問題はリロード時に生じているのではないかというのが、私の推測です。~これは、かなり核心を突いているかもしれません。~この仮説に基づいて、再度追跡してみます。コマンドの種類は変わらない~もしかしたら、この状態でMIDIファイルのエクスポートをしたら、~そのMIDIファイルも、当該のMARK文が欠落した状態かもしれませんね。~Museは演奏データとMIDIエクスポートデータを一元化しているので、~MIDIエクスポートデータは、そのまま演奏データのダンプデータとして活用できます。症状は生じていません。以外のモードでは症状は生じません。MIDIエクスポートデータは、そのまま演奏データのダンプデータとして活用できます。!早速試してみました。エクスポートをしても、正常なデータが出力されるのみです。依存ということも考えると、私の考えていたより問題の根は深いのでしょうか・・・~多分、メモリ上のデータは全て正常だと思います。~しかし、どこかでMuseがデータ以外のメモリを壊していることが考えられます。~症状はMARK表示の演奏時に出ますが、Elekenさんが推察されているとおり、~リロード(あるいはロード後の後処理)で既に破壊工作は完了しているのではないかと(苦笑)。メッセージが発行されていないようです~の件を追試してみましたので、ご報告します。~SetWindowText()をコールしている箇所で、デバッグライトにて~・SetWindowText()の戻り値~・SetWindowText()で送信している文字列内容~を確認してみました。~~なんと面妖なことに、Spy++でメッセージが送られていない状況でも、~・戻り値は、TRUE~・文字列は正常な30文字~が確認されました。~つまりデータは壊れていない、ということを裏付けていると思います。~~Elekenさんのご指摘の通り、演奏時点での症状から追跡するのを止めて、~データロード時点の不具合を追跡してみようと思います。Elekenさんが作ってくれた「純正培養データ」の純度を更に高めることができました。~結局、属性関係は無くても症状が出ますので、譜面モニタの属性表示はシロだったみたいです。~また、マクロの繰返し数で2000回指定をすると症状が出ません。~どうも、無名マクロの処理にバグが混入している気がしてきました。~今度こそ、犯人の潜むアジトを特定できるといいのですが・・・。Elekenさんが作ってくれた「純正培養データ」の純度を更に高めることができました。(↑この行が多い程、再現確率が高まる。10,000行あれば楽勝で出現)だいぶ敵陣に近づいてきたような気がします。~ただ、無名マクロの処理はとっても複雑なので、気が重いです。メモリダンプして解析したところ、次のことが分かりました。このアドレスのメモリが何を表すのか分かりませんし、他の環境でどうなるかもわかりませんが、この共通点は少し怪しそうです。末尾に来た場合、メッセージが飛んでいないようです。仕様の違いに関連ありそうとは思いましたが、これはという情報はまだ見つかってません。しなおしていない?のではないか、と思いました。末尾ではいけないのか?←これが問題ですね。してみようと思います。末尾に来た場合、メッセージが飛んでいないようです。謎(の一部)が解けました。ヒープ末尾を表すフラグだったわけです。終端がヒープ末尾に来る文字列の問題は、以下の簡単なプログラムで確認できます。呼び出した時点の残り割り当て可能領域に依存します。呼び出した時点の残り割り当て可能領域に依存します。~思い当たる節があります。~純正培養Museを作る過程で、本来必要なFree()部分をコメントアウトしたら、症状が出なくなりました。~また、機能を削り取ることで不要となった構造体のメンバをコメントアウトしたら、症状が出なくなったこともありました。そこを優先的に割り当ててしまうということなのでしょうか。ヒープ断片化が起こらないように、ヒープは自分で管理する。...のどれかをとればいいように思います。バイト多く確保する~これは、まさにV6.26aの対応そのものですね。する~今回の格闘の最中、実はこれを実施した記憶があります。~SendMessage()する前に、別途確保した文字列変数に問題の文字列内容をコピーし、~それをSendMessage()に送ってみました。すると、症状は出ませんでした。~ただ、演奏時点の処理負荷が増えるので、対応策としては却下していました。~~場当たり的に試行した私の実験と、論理的に導いたElekenさんの対応策の結果が見事に一致していますので、~Elekenさんの今回の真因推理はかなりの確度で正しいと思えます。ヒープ断片化が起こらないように、ヒープは自分で管理する。HeapCreate~私の技術力からして、この対応は継続的にメンテナンスしていく地震がありません。~じゃなかった、自信がありせん。いえば先程、横浜で比較的大きな自身がありました。~じゃなかった、地震がありました。...のどれかをとればいいように思います。バイト多く確保する」を正式な対応とすることが、~現時点では濃厚です。倍数バイトで発生しないのかも謎です。倍数バイトで発生しないのかも謎です。