According to user reports, this issue occurs on starting PIE from various game definitions. So far we have experienced a couple dozen of those crashes.
Steps to Reproduce
Hello,
Is this crash occurring on the Check() in GetD3D12TextureFromRHITexture or on the line above it?
FD3D12Texture* Result((FD3D12Texture*)RHITexture->GetTextureBaseRHI());If it’s the Check(), we have a similar crash and are considering removing this Check and allowing the calling code to handle a nullptr texture. Does it look like a nullptr texture in your crashes or something else?
We don’t have any crash reports that crash on this line, so it could be a memory stomp or a free after use. I recommend running with -rhivalidation on the machines where users experience this crash and also try -stompmalloc on a developer machine.
should those two parameters cause a big drop in performance?
Yes,-stompmalloc will drop performance and should only be run on a developer machine ideally. -rhivalidation will also drop performance but not as much, so I’d really just recommend using that on your internal machines where they’re experiencing the issue in Editor with PIE.
Unfortunately, I’m unable to reproduce this issue on my machine. Because of this, I’m unable to provide more information on this issue.
OK, I’m working on getting access to a build to investigate a couple issues and will update this thread if I discover more information about this.
Just wanted to post a reminder that Epic is on holiday break from 6/30 - 7/11, returning on 7/14. Confidential issues will be unanswered during that time but non-confidential issues will be answered, but likely with slower response times.
[mention removed] I have confirmed with one of the employees that has experienced this crash repeatedly that it also occurs when launching Unreal Editor with -rhivalidation parameter.
I’m looking forward to your reply once you are back from the holiday break.
[mention removed] We’re seeing a lot of crashes on this same line.
My assessment was the following -
FRHITexture* RHITexture = Texture;
#if D3D12RHI_USE_DUMMY_BACKBUFFER
if (RHITexture && EnumHasAnyFlags(RHITexture->GetFlags(), TexCreate_Presentable))
{
FD3D12BackBufferReferenceTexture2D* BufferBufferReferenceTexture = (FD3D12BackBufferReferenceTexture2D*)RHITexture;
RHITexture = BufferBufferReferenceTexture->GetBackBufferTexture();
}
#endif
RHITexture is not null initially, so BufferBufferReferenceTexture->GetBackBufferTexture() must returning null. Which under the hood means that the viewport’s CurrentBackBuffer_RHIThread->Texture is null. Not sure how that happens.
In my current instance, editor was in background and loading a level.
Hello,
Did you get a change to take a look at the issue?
Unfortunately, we are still experiencing it.
Hello,
I’ve been unable to get access to the build to troubleshoot locally, but am working on that today.
I have confirmed with one of the employees that has experienced this crash repeatedly that it also occurs when launching Unreal Editor with***-rhivalidation***parameter.
Are there any validation warnings or errors that appear in the logs when this happens?
[Content removed] but it’s not clear yet
Michal, can you confirm what the contents of the bad Texture pointer are? Is it a nullptr, a bad pointer? Are you able to track back to what texture was pointing to before this point?
According to the callstack, the Shader and Uniform Buffer are involved. If you repro the crash with r.shaders.extradata=1 in consolevariables.ini, the shader should have a name. The Uniform Buffer should also have a name. With both of these clues you should be able to determine the shader and texture resources it uses and determine what is going on with those textures - if the texture is getting released, you’ll want to check no code is holding onto a reference to it after it has been released.
I’ve been unable to get access to the build to troubleshoot locally, but am working on that today.
The access issue has been resolved.
Just wanted to update this ticket with the following information
- the texture is an internal Nanite texture
- the crash only occurs when the FastGeo plugin is enabled
I’ve reached out to my colleagues about whether the FastGeo plugin is the root cause and we think it is unlikely because the texture streaming changes made to support FastGeo are still used even if the FastGeo plugin is not enabled. It seems more likely the issue is related to timing changes with loading that only happens when FastGeo is enabled. If you can provide any more information about how to reproduce the issue or more details about the internal Nanite texture involved we may be able to make further progress.
I have talked to developers on our side. I was informed that a full on investigation on this issue is still in progress and so far it is limited to our code. I was asked to raise this issue again if it is determined that it is something on your side. I guess you may ignore this issue for now. Apologies for the inconvenience.
Thanks for the update, please let me know if I can be of assistance.
We experienced a similar problem with FastGeo when changing materials quality at runtime (via `r.MaterialQualityLevel` cvar). The solution was to write custom code that recreates render state of all FastGeo primitive components. This included waiting for any async FastGeo jobs, with PSO Precaching.
The following issue has been created for crashes that occur when changing r.MaterialQualityLevel at runtime with Fast Geo enabled:
UE-318822 Crash when changing r.MaterialQualityLevel when FastGeo plugin enabled in cooked build