Bug Report: Scene with GI component crashes when using camera sensor

[piotr-zyskowski-rai]

Describe the bug When testing the camera sensor, the crash happens on the scene containing the GI group elements The camera sensor is implemented by creating an additional rendering pipeline

Assets required See Found in Branch section for complete repositories configuration

Steps to reproduce

1. Open the scene containing the camera sensor component and GI light
2. Run play mode
3. The editor exits abnormally (nullptr dereference assert) Crash.log

Expected behavior The editor does not exit abnormally after the play mode run.

Actual behavior The editor exits abnormally (nullptr dereference assert) Crash.log

Screenshots/Video n/a

Found in Branch

• o3de commit: 89ab3eae4 + CascadePassFix patch applied
• o3de ros2 gem - feature/ros2-camera-sensor branch
  • the most interesting from rendering perspective is this file where pipeline is initialized and frames are requested
• resource heavy, GI light using scene

Desktop/Device (please complete the following information):

• Device: PC
• OS: Ubuntu
• Version 20.04
• CPU: Intel® Core™ i7-10750H CPU @ 2.60GHz × 12
• GPU NVIDIA GeForce RTX 3060 Laptop GPU
  • Total GPU memory: 6144 MB
  • Total Dedicated GPU Memory: 5946 MB
• Memory 31,2 GiB

Additional context

• The problem seems to be related to the GI_group lighting component. After removing it from the scene, a crash no longer occurs.
• Note that before the CascadePassFix, the crash was the freeze was occurring

[lmbr-pip]

Crashing in RHI code:

==================================================================
(System) - Trace::Assert
 /home/pzyskowski/project/o3de/o3de/Code/Framework/AzCore/./AzCore/std/smart_ptr/intrusive_ptr.h(183): (140673444640064) 'T &AZStd::intrusive_ptr<AZ::RHI::Device>::operator*() const [T = AZ::RHI::Device]'
(System) - You can't dereference a null pointer
(System) - ------------------------------------------------
(System) - AZ::RHI::DeviceObject::GetDevice() const (+0x40) [0x7ff0d629ade0]
(System) - AZ::Vulkan::Image::Invalidate() (+0x42) [0x7ff0d62222c2]
(System) - AZ::Vulkan::Image::~Image() (+0x23) [0x7ff0d62221c3]
(System) - AZ::Vulkan::Image::~Image() (+0x1b) [0x7ff0d62225db]
(System) - AZ::RHI::AliasedHeap::ActivateImage(AZ::RHI::TransientImageDescriptor const&, AZ::RHI::Scope&, AZ::RHI::Image**) (+0x4ed) [0x7ff0d62e4e9d]
(System) - AZ::RHI::AliasedAttachmentAllocator<AZ::Vulkan::AliasedHeap>::ActivateImage(AZ::RHI::TransientImageDescriptor const&, AZ::RHI::Scope&) (+0x94) [0x7ff0d61b08c4]
(System) - AZ::Vulkan::TransientAttachmentPool::ActivateImage(AZ::RHI::TransientImageDescriptor const&) (+0x65) [0x7ff0d61afa45]
(System) - AZ::RHI::FrameGraphCompiler::CompileTransientAttachments(AZ::RHI::FrameGraph&, AZ::RHI::TransientAttachmentPool&, AZ::RHI::FrameSchedulerCompileFlags, AZ::RHI::FrameSchedulerStatisticsFlags)::$_0::operator()(AZ::RHI::TransientAttachmentPoolCompileFlags, A
(System) - AZ::RHI::FrameGraphCompiler::Compile(AZ::RHI::FrameGraphCompileRequest const&) (+0xa9) [0x7ff0cf803dc9]
(System) - AZ::RHI::FrameScheduler::Compile(AZ::RHI::FrameSchedulerCompileRequest const&) (+0x164) [0x7ff0cf7c3234]
(System) - AZ::RHI::RHISystem::FrameUpdate(AZStd::function<void (AZ::RHI::FrameGraphBuilder&)>) (+0x202) [0x7ff0cf7fd5a2]
(System) - AZ::RPI::RPISystem::RenderTick() (+0x19f) [0x7ff0cf32113f]

[moudgils]

@piotr-zyskowski-rai - This is an old issue. Is it still valid? If not lets close it.