プロジェクト、およびWindowsパッケージをBOXアップロードいたしました。
UE5.7.2ベースのソースエンジンで確認しておりますが、LauncherのUE5.7.4でも10分ほどエージングテストを行いクラッシュが発生しないことを確認しておりますのでご確認いただけますと幸いです。
[Attachment Removed]
ありがとうございます。
頂いた exe を実行したところ、同様のクラッシュが発生することを確認致しました。
BOX に .log をアップロードしましたので、お手数ですがご確認頂いても宜しいでしょうか。
度々申し訳ございませんが、宜しくお願い致します。
[Attachment Removed]
ログファイルを見てみたいと思いますが、クラッシュが発生するにあたって何か特別な操作や経過時間、テスト方法など特別な条件などはありますでしょうか？
こちらで確認した際には再現が確認できなかったのですが、テスト条件の違いを確認したく思います。
また、プロジェクトをアップロードさせて頂きましたが、コンポーネント構成等には問題がございませんでしょうか。BeginPlayまでの間はSetRootComponent が発生しないため、それが許容されるかどうかはこの回避策の考慮すべき点となります。コンポーネントの構成を極力変えない方法での回避策を考慮した上で提示させて頂きましたが、RecreateComponentHierarchy()の実行タイミング自体を変えること（Loading中の外に逃がす）等はプロジェクト側での制約により困難でしょうか？
[Attachment Removed]
> クラッシュが発生するにあたって何か特別な操作や経過時間
操作については Windows フォルダ直下にある .exe を実行しているのみとなっています。
頂いたパッケージで何度か試してみましたが、おおよそ 10 秒から 1 分経過せずにクラッシュが発生している状況です。
> BeginPlayまでの間はSetRootComponent が発生しないため、それが許容されるかどうかはこの回避策の考慮すべき点となります。
> コンポーネントの構成を極力変えない方法での回避策を考慮した上で提示させて頂きましたが、RecreateComponentHierarchy()の実行タイミング自体を変えること（Loading中の外に逃がす）等はプロジェクト側での制約により困難
一度、本プロジェクト側で検証致します。
この BP は LevelSequence によって各 SceneComponent に対して移動や回転が行われるものでして、
SetRootComponent は大丈夫そうではあるものの、階層構造の変更については影響がある可能性がございます。
お手数ですが、宜しくお願い致します。
[Attachment Removed]
お世話になっております。
> 本プロジェクト側で検証
SetRootComponent のみを遅らせる場合、StaticMesh が RootComponent のまま階層変更をしようとするため、
USceneComponent::AttachToComponent 内で StaticMeshComponent0 root component cannot be attached to other components in the same actor. Aborting. の Warning に引っかかってしまっており、
階層変更が適切に行われていない関係でこちらの手法は取れなさそうでした。
SetRootComponent を含めた RecreateComponentHierarchy() を BeginPlay へ移動する形については
LevelSequence での編集時など、Editor で該当の BP を操作する際には階層構造が変更された状態が望ましいため、
void ASequenceAnimationStaticMeshActor::PostLoad()
{
Super::PostLoad();
#if WITH_EDITOR
RecreateComponentHierarchy();
#endif
}
Editor のみ PostLoad で処理するという形で問題なければ許容できるのではと考えています。
[Attachment Removed]
ご確認頂きありがとうございます。
RecreateComponentHierarchy() を BeginPlay へ移動する形については、パッケージビルドでは RecreateComponentHierarchy() がPostLoadで呼ばれなくなるため、C++ コンストラクタが生成するコンポーネント階層とアーキタイプの不一致が生じなくなり、クラッシュのトリガーを回避できます。Editor では PostLoad() で階層が再構築されるため LevelSequence 編集時の要件も満たされます。確認してべき点として、RecreateComponentHierarchy() の処理内容がパッケージビルドのゲームプレイに影響するか、例えばレベルのアンロード→リロードが繰り返されるシナリオでは BeginPlay が複数回呼ばれる可能性があるため RecreateComponentHierarchy() が何度呼んでも同じ結果になるかをご確認頂くことをお勧めいたします。
[Attachment Removed]
ありがとうございます。
> RecreateComponentHierarchy() の処理内容がパッケージビルドのゲームプレイに影響するか、
> 例えばレベルのアンロード→リロードが繰り返されるシナリオでは BeginPlay が複数回呼ばれる可能性があるため RecreateComponentHierarchy() が何度呼んでも同じ結果になるか
RecreateComponentHierarchy 内で行っている Attach や Mobility の設定などについては複数回コールされてもエンジン内でのチェックではじかれるため、動作は問題なさそうでした。
> パッケージビルドでは RecreateComponentHierarchy() がPostLoadで呼ばれなくなるため、C++ コンストラクタが生成するコンポーネント階層とアーキタイプの不一致が生じなくなり、クラッシュのトリガーを回避
改修頂いたサンプル含め、ASequenceAnimationStaticMeshActor のコンストラクタを
// ルート
this->SceneRootComponent = CreateDefaultSubobject<USceneComponent>(FName(TEXT("SceneRootComponent")));
// 回転打ち消し用のコンポーネント
this->UnrotateComponent = CreateDefaultSubobject<USceneComponent>(FName(TEXT("UnrotateComponent")));
// アニメーション用のコンポーネント
this->AnimationComponent = CreateDefaultSubobject<USceneComponent>(FName(TEXT("AnimationComponent")));
のみ行うようにもしてみましたが、クラッシュを回避することはできないようでした…
参考になるかわかりませんが、引き続き、宜しくお願い致します。
[Attachment Removed]
お世話になっております。
[Content removed]
ご相談させて頂いている件、もしかしたら上記の不具合を踏んでいる可能性がございます。
(同じように CustomPrimitiveDataInternal のコピー時と思われるタイミングでのクラッシュとなっています)
一度こちらの CL を適応して試してみたいと思います。
[Attachment Removed]
お世話になっております。
情報を共有頂きありがとうございます。コールスタックと発生状況を見る限りではこの修正が有効な可能性がありそうです。CLを適用してみてお試しいただければと思います。
[Attachment Removed]
お世話になっております。
提示されていた CL を適応したエンジンにてサンプルを実行してみたところ、1 時間以上クラッシュが発生しない状態になることを確認致しました。
アプリケーション側でも問題無いかの検証を進めていきたいと思います。
[Attachment Removed]
状況を共有いただきありがとうございます。プロジェクト側での有効性が高いと思われますので、ぜひ検証を行って頂けますと幸いです。
[Attachment Removed]
お世話になっております。
アプリケーション側で検証を行ってみたところ、ご報告させて頂いたエラーが発生しなくなりました。
こちら、クローズして頂いて問題ございません。
長期に渡るご対応ありがとうございました。
[Attachment Removed]
ご確認および結果を共有頂きありがとうございました。最初に当該スレッドを見つけておけばもう少し早期の解決が実現できたと思う次第で、ご不便をお掛けしており申し訳ございませんでした。こちらこそ、問題を継続的に検証して頂きありがとうございました。
[Attachment Removed]