4.0 beta 6 crash often with GPUParticles3D

[wdv4758h]

Godot version

4.0.beta6.official.7f8ecffa5

System information

Arch Linux, Vulkan, NVIDIA GeForce RTX 2060

Issue description

Not sure what's the root trigger. It has many actions that can trigger crash or hang. Like swapping texture for the QuadMesh particle. But it's not always happen. Sometime a project restart will make the actions fine again.

The backtrace:

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.beta6.official (7f8ecffa56834dce3ccbd736738b613d51133dea)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x38a00) [0x7f74fb091a00] (??:0)
[2] /usr/bin/godot() [0x2973701] (??:0)
[3] /usr/bin/godot() [0x298afc2] (??:0)
[4] /usr/bin/godot() [0x29c6f01] (??:0)
[5] /usr/bin/godot() [0xe5e375] (??:0)
[6] /usr/bin/godot() [0xd98200] (??:0)
[7] /usr/lib/libc.so.6(+0x23290) [0x7f74fb07c290] (??:0)
[8] /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7f74fb07c34a] (??:0)
[9] /usr/bin/godot() [0xdb974e] (??:0)
-- END OF BACKTRACE --
================================================================

Steps to reproduce

Create a GPUParticles3D node. Use QuadMesh. Apply some textures and switch between textures. Maybe try different settings, transparency alpha, shading unshaded, blend mode add, particle billboard. I don't have a reliable way to reproduce for now.

Here is some steps that I did to see the crash, but it's not always happening.

1. create new project
2. add 3D scene
3. add GPUParticles3D node
4. assign new ParticleProcessMaterial to GPUParticles3D
5. assign new QuadMesh to GPUParticles3D's pass 1
6. assign new StandardMaterial3D to QuadMesh
7. drag icon.svg to QuadMesh's StandardMaterial3D

If it's not crash after apply icon.svg. Try changing the shading mode, back and forth between different mode. And try reapply icon.svg from time to time.

Minimal reproduction project

godot-bug-gpuparticles.zip

[colinmbo]

Possibly related to #65732 ?

[wdv4758h]

I updated the description for more info. And a simple project I've used to reproduce the crash.

And here is a video for what I did to see the crash, hope it helps:

godot-4.0-gpupartciles3d-crash.mp4

[wdv4758h]

It may crash in different actions. But basically with stuffs mentioned in the list. Tweak here and there, then it happened.

[andyprice]

This is the backtrace I get when this bug occurs for me:

handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.beta.custom_build (63f95c0e58e51ec2939e8b47803cb607fb35cadc)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /lib64/libc.so.6(+0x3cb50) [0x7f1503199b50] (??:0)
[2] CowData<RendererRD::TextureStorage::RenderTarget*>::size() const (/home/andy/src/godot/./core/templates/cowdata.h:133)
[3] Vector<RendererRD::TextureStorage::RenderTarget*>::size() const (/home/andy/src/godot/./core/templates/vector.h:90)
[4] RendererRD::MaterialStorage::MaterialData::set_as_used() (/home/andy/src/godot/servers/rendering/renderer_rd/storage_rd/material_storage.cpp:1474)
[5] void RendererSceneRenderImplementation::RenderForwardClustered::_render_list_template<(RendererSceneRenderImplementation::RenderForwardClustered::PassMode)0, 0u>(long, long, RendererSceneRenderImplementation::RenderForwardClustered::RenderListParameters*, unsigned int, unsigned int) (/home/andy/src/godot/servers/rendering/renderer_rd/forward_clustered/render_forward_clustered.cpp:?)
[6] RendererSceneRenderImplementation::RenderForwardClustered::_render_list(long, long, RendererSceneRenderImplementation::RenderForwardClustered::RenderListParameters*, unsigned int, unsigned int) (/home/andy/src/godot/servers/rendering/renderer_rd/forward_clustered/render_forward_clustered.cpp:544)
[7] RendererSceneRenderImplementation::RenderForwardClustered::_render_list_with_threads(RendererSceneRenderImplementation::RenderForwardClustered::RenderListParameters*, RID, RenderingDevice::InitialAction, RenderingDevice::FinalAction, RenderingDevice::InitialAction, RenderingDevice::FinalAction, Vector<Color> const&, float, unsigned int, Rect2 const&, Vector<RID> const&) (/home/andy/src/godot/servers/rendering/renderer_rd/forward_clustered/render_forward_clustered.cpp:607)
[8] RendererSceneRenderImplementation::RenderForwardClustered::_render_scene(RenderDataRD*, Color const&) (/home/andy/src/godot/servers/rendering/renderer_rd/forward_clustered/render_forward_clustered.cpp:1910)
[9] RendererSceneRenderRD::render_scene(Ref<RenderSceneBuffers> const&, RendererSceneRender::CameraData const*, RendererSceneRender::CameraData const*, PagedArray<RenderGeometryInstance*> const&, PagedArray<RID> const&, PagedArray<RID> const&, PagedArray<RID> const&, PagedArray<RID> const&, PagedArray<RID> const&, PagedArray<RID> const&, RID, RID, RID, RID, RID, RID, int, float, RendererSceneRender::RenderShadowData const*, int, RendererSceneRender::RenderSDFGIData const*, int, RendererSceneRender::RenderSDFGIUpdateData const*, RenderingMethod::RenderInfo*) (/home/andy/src/godot/servers/rendering/renderer_rd/renderer_scene_render_rd.cpp:1167)
[10] RendererSceneCull::_render_scene(RendererSceneRender::CameraData const*, Ref<RenderSceneBuffers> const&, RID, RID, unsigned int, RID, RID, RID, RID, int, float, bool, RenderingMethod::RenderInfo*) (/home/andy/src/godot/servers/rendering/renderer_scene_cull.cpp:3270)
[11] RendererSceneCull::render_camera(Ref<RenderSceneBuffers> const&, RID, RID, RID, Vector2, bool, float, RID, Ref<XRInterface>&, RenderingMethod::RenderInfo*) (/home/andy/src/godot/servers/rendering/renderer_scene_cull.cpp:2551)
[12] RendererViewport::_draw_3d(RendererViewport::Viewport*) (/home/andy/src/godot/servers/rendering/renderer_viewport.cpp:211)
[13] RendererViewport::_draw_viewport(RendererViewport::Viewport*) (/home/andy/src/godot/servers/rendering/renderer_viewport.cpp:269)
[14] RendererViewport::draw_viewports() (/home/andy/src/godot/servers/rendering/renderer_viewport.cpp:711)
[15] RenderingServerDefault::_draw(bool, double) (/home/andy/src/godot/servers/rendering/rendering_server_default.cpp:92)
[16] RenderingServerDefault::draw(bool, double) (/home/andy/src/godot/servers/rendering/rendering_server_default.cpp:393)
[17] Main::iteration() (/home/andy/src/godot/main/main.cpp:3205)
[18] OS_LinuxBSD::run() (/home/andy/src/godot/platform/linuxbsd/os_linuxbsd.cpp:878)
[19] /home/andy/src/godot/bin/godot.linuxbsd.editor.dev.x86_64.llvm(main+0x1f5) [0x2332b55] (/home/andy/src/godot/platform/linuxbsd/godot_linuxbsd.cpp:73)
[20] /lib64/libc.so.6(+0x27510) [0x7f1503184510] (??:0)
[21] /lib64/libc.so.6(__libc_start_main+0x89) [0x7f15031845c9] (??:0)
[22] /home/andy/src/godot/bin/godot.linuxbsd.editor.dev.x86_64.llvm(_start+0x25) [0x2332895] (??:?)

[GrauBlitz]

• create new project

• add 3D scene

• add GPUParticles3D node

• assign new ParticleProcessMaterial to GPUParticles3D

• assign new QuadMesh to GPUParticles3D's pass 1

• assign new StandardMaterial3D to QuadMesh

• drag icon.svg to QuadMesh's StandardMaterial3D

This works for me, but when i change the transparency in the StandardMaterial3D the editor freezes/crashes for me.

[dmaz]

I haven't edited any GPU particles in a few weeks until today. on today's current build I'm finding the process very unstable compared to the last time. for the longest time godot wouldn't crash but just report a bunch of errors (often "uniforms were never supplied") but those could be overcome by switching to another scene and then back again. now though I get full-on hangs or crashes when trying to change material options.

I regressed to a754930 from dec 29 and I now get the wall of errors again but no crashes.

my process to get the hangs or crashes was just creating a new GPUParticle3D, adding a pass 1 mesh, adding a material for that mesh.

then just start messing with the material like what was noted above or in my case changing transparency or vertex color...

update:

• ok I seem to only get the crashes or hangs if I try to alter the material right away without first saving the scene. (and hence the material)
• on today's build if I add a material and then save the scene I get the "uniform were never supplied" again but switching off the scene and back on fixes that. so I'm thinking I was probably used to that workflow previously

[elvisish]

I had non-stop issues with mobile rendering but after switching to forward+ I haven't noticed any problems whatsoever with GPUParticles.

[clayjohn]

After some investigation, this looks like a threading issue. My guess is that the material is getting freed/cleared after the rendering thread has been a reference to the material. The renderer isn't properly updating the reference in that case and then continues to try to use the old material/material information.

My guess is that the solution will involve either:
a) adding synchronization primitives to the internal MaterialRD classes or
b) adding more robust checks/caching in the renderer to avoid trying to draw objects that have just been changed

I think #67548 may have the same root cause