お世話になっております。
<br/>
UE5.7.2で作成したプロジェクトで、特定画面上で放置した際にクラッシュが発生しております。
手元の環境でも再現が取れておらず、クラッシュの起因となる物が不明な状態です。
こちらUE5.8で修正等行われていたりしないでしょうか。
ご確認のほどよろしくお願いします。
<br/>
内容としては下記の通りで、FD3D12OfflineDescriptorManagerのクリーンアップ後にClearUAVが行われていることが原因であると認識しています。
1.FD3D12CommandContext::ClearUAV関数内で「RHICmdList.RunOnContext」で登録された関数のスコープから抜ける
2.その際に関数内で定義された「FD3D12UnorderedAccessView UAV」が破棄される
3.基底クラスFD3D12ViewのデストラクタでFD3D12OfflineDescriptorManager::FreeHeapSlotが呼ばれる
4.FD3D12OfflineDescriptorManagerのメンバHeapsが不正な値になっており「HeapEntry.FreeList.GetHead()」でクラッシュ
追記：コールスタックが表示されていなかったため、テキスト形式での添付をさせていただきました。
[Attachment Removed]
お待たせしております。
「FD3D12OfflineDescriptorManagerのクリーンアップ後」とありますが、アプリケーションが何らかの原因で閉じられたことがトリガーになっているということでよろしいでしょうか？
コールスタックでは直接例外を発生させたタスクスレッドのみが見えており、RenderThreadなどの状態を確認できません
他のスレッドのコールスタックやダンプが残っていればご共有いただけますと幸いです。
Shipping以外のビルドでも同様の問題が発生しうるか現時点での再現性についても伺えますでしょうか。
>FD3D12OfflineDescriptorManagerのメンバHeapsが不正な値になっており
コールスタックの位置でクラッシュが発生しているならFD3D12OfflineDescriptorManager自体が不正な状態になっていることが考えらえます。
ダンプ等で確認できた情報があればご共有ください。
現時点ではFD3D12OfflineDescriptorManagerに関連するバグ登録やEPSの投稿は見つけられておりません。
またUE5.8でクラッシュと関連するような変更が D3D12DescriptorsやD3D12UAVに加えられたようには見えない状態となっております。
[Attachment Removed]
ご確認ありがとうございます。
>「FD3D12OfflineDescriptorManagerのクリーンアップ後」とありますが、アプリケーションが何らかの原因で閉じられたことがトリガーになっているということでよろしいでしょうか？
クラッシュ発生時の録画等を行っておらず、瞬間の確認は確認できていないため、何がトリガーになっているかも不明の状態です。
Testビルドでの再現確認も数度行っていましたが、現状再現取れていません。
>FD3D12OfflineDescriptorManagerのメンバHeapsが不正な値になっており
改めてダンプの確認を行いましたが、thisポインタ自体、「FD3D12OfflineDescriptorManager」自体には問題無さそうでした。
「auto Node = HeapEntry.FreeList.GetHead();」でのアクセス違反であることと、Heaps変数内のメンバHeapの中身が評価できない、FreeListが「Unable read to memory」と表示されていることから「Heapsが不正な値」と共有させていただいていました。
>RenderThreadのコールスタックについて
CrashContextに出力されているRenderThreadのコールスタックからWinDbgを使用して確認した内容をテキストファイルで共有させていただきます。
「FWindowsPlatformProcess::Sleep」でスレッドをスリープさせている状態のようです。
RenderThreadのスリープ中にClearUAVが行われたことによる問題の可能性はありますでしょうか。
お手数ですがご確認のほどよろしくお願いします。
[Attachment Removed]
RenderThreadのコールスタックについてはシンボルが解決されておらず有用な情報をえることが出来ませんでした。なんらかの有用なシンボルを含むものが得られると判断につながる可能性があります。
> 改めてダンプの確認を行いましたが、thisポインタ自体、「FD3D12OfflineDescriptorManager」自体には問題無さそうでした。～
まず前提としてShippingビルドのダンプを見る場合、最適化によって変数が正しく解決されないケースが多々あります。正しい値を取得するためにはスタックやレジスタの値を参照しなければならないケースが多いです。
Heaps配列は正常(コンテナ自体は破損していない)だったが、配列のエレメントの FD3D12OfflineHeapEntry はHeapやFreeListには有効なポインタが格納されていないということでよろしいでしょうか？
実際の状態を見てみないと判断できませんが、有効な状態の配列要素を保持していないコンテナはすでに破壊されているようにも感じます。
this(FD3D12OfflineDescriptorManager)が問題無いという判断にいたったのは、Heaps以外の他のメンバ変数の値が想定される数値になっていたということでしょうか？
現時点の情報ではこのクラッシュが発生する前に別の不正処理によってアプリケーションがシャットダウンしている最中の問題なのではないかと推測しています。
Shippingビルドでなら問題が再現可能なのであれば *,Target.cs で bUseLoggingInShipping を有効にして問題を再現できるとクラッシュ直前の情報が得られる可能性がございます。
[Attachment Removed]
ご確認ありがとうございます。
>RenderThreadのコールスタックについてはシンボルが解決されておらず有用な情報をえることが出来ませんでした。
こちら改めてシンボルの解決を行ってからコールスタックの取得を行いましたので、添付させていただきます。
>this(FD3D12OfflineDescriptorManager)が問題無いという判断にいたったのは、Heaps以外の他のメンバ変数の値が想定される数値になっていたということでしょうか？
その認識です。
メンバのHeapsとFreeHeapsが有効でない状態で、それ以外のメンバや自身のアドレスに関しては異常が見られない状態でした。
スクショを取ろうとしたのですが、手違いで.exeを削除してしまって添付できませんでした。
再現取れ次第に共有させていただきます。
bUseLoggingInShippingについても共有ありがとうございます。
有効にしての再現確認を行わせていただきます。
お手数ですが、レンダースレッドのコールスタックから何か情報が得られないか、ご確認のほどよろしくお願いします。
[Attachment Removed]
ご調査ありがとうございます。
レンダースレッドは描画の準備中でFinishGatherDynamicMeshElementsで停止しています。一方クラッシュスレッドはGatherDynamicMeshElementのタスクではないため因果関係が直接は繋がっていません。
FD3D12OfflineDescriptorManagerが問題無いように見えることについて承知しました。FD3D12OfflineDescriptorManager::CleanupResourcesは配列の破壊を伴わないため、恐らくこのクラス自体がデストラクトされた状態にあると思われます。ここで一点確認したいのはHeapTypeが0かどうかです。ゼロであれば正常ですが非ゼロなら不正な状態です。
さてこのクラスがデストラクトされるとき、GameThreadではFD3D12DynamicRHI::Shutdown関数内のChosenAdapters.Empty()を通過している可能性が高いですが
しかしながら通常はこのまえにレンダリングスレッドの同期待ちが入るので正規のパスでデストラクトされることは非常に考えにくいです。
大変申し訳ありませんがこの点について確認するために、ゲームスレッドの状態について調べていただくことは可能でしょうか？
もしゲームスレッドのコールスタックにFEngineLoop::Exitが見えたならば何らかの原因でShutdownに入り、レンダリングスレッドの同期を待たずに終了した可能性があります。
ゲームスレッドがシャットダウン処理の途上にない場合、周辺のメモリの破壊のような現象が起こったことが疑われます。
上記2点をご確認いただけますでしょうか。
[Attachment Removed]
お世話になっております。
返答が遅れてしまい申し訳ありません。
>HeapTypeが0かどうか
FD3D12OfflineDescriptorManager::FreeHeapSlot時の情報をFreeHeapSlotVariables.txtとして添付させていただきました。
結果としてはHeapTypeは「Standard (0x0)」になっております。
>ゲームスレッドの状態について
GameThreadCallStack.txtにコールスタックを添付させていただきました。
「FEngineLoop::Exit」は通っていないことを確認しています。
今回の問題に関係しているかは不明ですが、1点情報共有させていただきます。
このクラッシュを確認したPCで発生していた別件のクラッシュが、CPU側の設定変更で改善したことを確認しております。
対応内容としてはIntel i9-14900Kで発生している不安定性を回避するために「Intel Turbo Boost Max Technology 3.0」を無効化する対応でした。
この対応で今回の問題に改善が見られるかは不明ですが、QAの方に再現確認を依頼している状態です。
こちらは結果が返り次第にこちらにも共有させていただきます。
以上共有になります。
ご確認のほどよろしくお願いします。
[Attachment Removed]
追加情報の共有ありがとうございます。
このコールスタックにより明確にアプリケーションがシャットダウン中ではなく通常の1フレームを処理中であることが支持されました。
さらにメモリダンプによる周辺のメモリが正常の範囲内であることも確認できました。
FreeListは複数のスレッドからアクセスされる可能性はありますがアクセスはCriticalSectionで保護されており、
ClearUAV関数内での短いライフタイムの中で大きく状態が変化することは考えにくくソフトウェア上の不具合とは見なせないです。
Core 13世代または14世代の不安定さは弊社のタイトルでも過去に報告されており、特定のPC上で有意なクラッシュ解析結果をもたらさない不安定なクラッシュを引き起こします。
ISPCなどの特定のコードを回避することで改善する事例はありましたが根本的な解決策ではなく、ハードウェアの一時的または過電流によるハードウェアの故障が原因となります。
既にご参照されていると思いますがIntel社による情報共有のリンクを以下に共有します。
https://community.intel.com/t5/Blogs/Tech\-Innovation/Client/Intel\-Core\-13th\-and\-14th\-Gen\-Desktop\-Instability\-Root\-Cause/post/1633239
> この対応で今回の問題に改善が見られるかは不明ですが、QAの方に再現確認を依頼している状態です。
> こちらは結果が返り次第にこちらにも共有させていただきます。
承知しました。
[Attachment Removed]
お世話になっております。
こちら添付していただいたリンクの内容を参考に下記対応を行ったところ、再現しなくなったことを確認できました。
諸々のご確認ありがとうございました。
>・BIOSのアップデートの実施
>・「Intel Turbo Boost Max Technology 3.0」の設定を「Disabled」に変更
>・電力プロファイル「Power Dlivery Profile」＞「BIOS Default」に変更
[Attachment Removed]