Editor crashes on project load: "pure virtual method called"

Godot version
4.0 dev d11117d9d8ae32d6acc025a7495d4ae58b9c37b4
System information
Arch Linux, KDE Plasma, Radeon RX6800XT, amdgpu driver, Vulkan
Issue description
For more than a week now I have been unable to open a project I'm working on.
Godot editor crashes while loading the project. I have bisected by project commits to maybe see what in my project has triggered this engine bug, but what I found doesn't seem to make any sense, and when I tried it again to checkout the last known good commit - it crashes as well, so I don't think this will be helpful unfortunately.
What's interesting is if the assets are already imported, the game will run but not load in the editor.
If the assets are not imported, the editor crashes before any of them are - the .godot/imported/ folder stays empty.
I've been testing Calinou's nightly builds every couple of days, hoping this will go away. The crashes didn't stop, but the crash messages are changing here and there.
I've been asking for help with this issue on Godot Contributors Chat.
I have tried clearing all possible cache - it's one of the first things I try in such cases.
I have tried removing recently created shader assets from my project since shader compilation errors were present as well.
I have tried switching to single-threaded rendering, following a suggestion from @RandomShaper .
I compiled Godot myself with a a patch from @bruvzg and I thought it solved the problem, but it was a just fluke.
Before finally posting here I have just compiled Godot 4.0-dev from source and tested to confirm this has not been fixed. Here's the current backtrace:
[Thread 0x7fffa8ffd6c0 (LWP 1677949) exited]

Thread 1 "godot.linuxbsd." received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000055555b428e49 in CommandQueueMT::_flush (this=0x5555612f21d0) at ./core/templates/command_queue_mt.h:373
#2  0x000055555b428ede in CommandQueueMT::flush_if_pending (this=0x5555612f21d0) at ./core/templates/command_queue_mt.h:404
#3  0x000055555b440cf6 in RenderingServerDefault::global_shader_uniform_get_type (this=0x5555612f1f90, p1=...) at servers/rendering/rendering_server_default.h:916
#4  0x000055555b486010 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#5  0x000055555b4b85ca in ShaderLanguage::_parse_shader (this=0x5555619f0288, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8292
#6  0x000055555b4c54b9 in ShaderLanguage::compile (this=0x5555619f0288, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9677
#7  0x000055555b486125 in ShaderCompiler::compile (this=0x5555619f0288, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffffffc7a0, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#8  0x000055555b5e3fc9 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557bb35710, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#9  0x000055555b61ebfa in RendererRD::MaterialStorage::shader_set_code (this=0x5555613b9780, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#10 0x000055555b477c7f in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffb81d1b20) at ./core/templates/command_queue_mt.h:322
#11 0x000055555b428e49 in CommandQueueMT::_flush (this=0x5555612f21d0) at ./core/templates/command_queue_mt.h:373
#12 0x000055555b428ede in CommandQueueMT::flush_if_pending (this=0x5555612f21d0) at ./core/templates/command_queue_mt.h:404
#13 0x000055555b44103d in RenderingServerDefault::free (this=0x5555612f1f90, p_rid=...) at servers/rendering/rendering_server_default.h:931
#14 0x000055555a0127db in CanvasItem::~CanvasItem (this=0x5555755bb370, __in_chrg=<optimized out>) at scene/main/canvas_item.cpp:1183
#15 0x00005555582dd348 in Control::~Control (this=0x5555755bb370, __in_chrg=<optimized out>) at ./scene/gui/control.h:45
#16 0x000055555a337278 in Range::~Range (this=0x5555755bb370, __in_chrg=<optimized out>) at scene/gui/range.cpp:335
#17 0x000055555a332de4 in ProgressBar::~ProgressBar (this=0x5555755bb370, __in_chrg=<optimized out>) at scene/gui/progress_bar.h:36
#18 0x0000555557f2033f in memdelete<Node> (p_class=0x5555755bb370) at ./core/os/memory.h:109
--Type <RET> for more, q to quit, c to continue without paging--
#19 0x000055555a06ace7 in Node::_notification (this=0x5555755bbbb0, p_notification=1) at scene/main/node.cpp:169
#20 0x0000555557c1345c in Node::_notificationv (this=0x5555755bbbb0, p_notification=1, p_reversed=true) at scene/main/node.h:45
#21 0x00005555582db2ad in CanvasItem::_notificationv (this=0x5555755bbbb0, p_notification=1, p_reversed=true) at ./scene/main/canvas_item.h:45
#22 0x00005555582db9e9 in Control::_notificationv (this=0x5555755bbbb0, p_notification=1, p_reversed=true) at scene/gui/control.h:46
#23 0x000055555c0b7bbf in Object::notification (this=0x5555755bbbb0, p_notification=1, p_reversed=true) at core/object/object.cpp:735
#24 0x000055555c0b56bd in Object::_predelete (this=0x5555755bbbb0) at core/object/object.cpp:195
#25 0x000055555c0c1df3 in predelete_handler (p_object=0x5555755bbbb0) at core/object/object.cpp:1777
#26 0x0000555557f2031f in memdelete<Node> (p_class=0x5555755bbbb0) at ./core/os/memory.h:105
#27 0x000055555a06ace7 in Node::_notification (this=0x555575718480, p_notification=1) at scene/main/node.cpp:169
#28 0x0000555557c1345c in Node::_notificationv (this=0x555575718480, p_notification=1, p_reversed=true) at scene/main/node.h:45
#29 0x00005555582db2ad in CanvasItem::_notificationv (this=0x555575718480, p_notification=1, p_reversed=true) at ./scene/main/canvas_item.h:45
#30 0x00005555582db9e9 in Control::_notificationv (this=0x555575718480, p_notification=1, p_reversed=true) at scene/gui/control.h:46
#31 0x00005555582dc239 in Container::_notificationv (this=0x555575718480, p_notification=1, p_reversed=true) at ./scene/gui/container.h:37
#32 0x00005555582dc975 in BoxContainer::_notificationv (this=0x555575718480, p_notification=1, p_reversed=true) at ./scene/gui/box_container.h:37
#33 0x00005555582dd263 in HBoxContainer::_notificationv (this=0x555575718480, p_notification=1, p_reversed=true) at ./scene/gui/box_container.h:72
#34 0x000055555c0b7bbf in Object::notification (this=0x555575718480, p_notification=1, p_reversed=true) at core/object/object.cpp:735
#35 0x000055555c0b56bd in Object::_predelete (this=0x555575718480) at core/object/object.cpp:195
#36 0x000055555c0c1df3 in predelete_handler (p_object=0x555575718480) at core/object/object.cpp:1777
#37 0x000055555922dbe3 in memdelete<HBoxContainer> (p_class=0x555575718480) at ./core/os/memory.h:105
--Type <RET> for more, q to quit, c to continue without paging--c
#38 0x000055555922a9b0 in BackgroundProgress::_end_task (this=0x555569a357d0, p_task=...) at editor/progress_dialog.cpp:94
#39 0x0000555557ad1d21 in call_with_variant_args_helper<__UnexistingClass, String const&, 0ul> (p_instance=0x555569a357d0, p_method=(void (__UnexistingClass::*)(__UnexistingClass * const, const String &)) 0x55555922a8d2 <BackgroundProgress::_end_task(String const&)>, p_args=0x7fffffffd2a0, r_error=...) at ./core/variant/binder_common.h:262
#40 0x0000555557ad190e in call_with_variant_args_dv<__UnexistingClass, String const&> (p_instance=0x555569a357d0, p_method=(void (__UnexistingClass::*)(__UnexistingClass * const, const String &)) 0x55555922a8d2 <BackgroundProgress::_end_task(String const&)>, p_args=0x7fffffffd4b0, p_argcount=1, r_error=..., default_values=...) at ./core/variant/binder_common.h:409
#41 0x0000555557ad14c2 in MethodBindT<String const&>::call (this=0x555569a36410, p_object=0x555569a357d0, p_args=0x7fffffffd4b0, p_arg_count=1, r_error=...) at ./core/object/method_bind.h:320
#42 0x000055555c0b77fb in Object::callp (this=0x555569a357d0, p_method=..., p_args=0x7fffffffd4b0, p_argcount=1, r_error=...) at core/object/object.cpp:678
#43 0x000055555bd77c9c in Callable::callp (this=0x7fffe62b8038, p_arguments=0x7fffffffd4b0, p_argcount=1, r_return_value=..., r_call_error=...) at core/variant/callable.cpp:62
#44 0x000055555c0b19a0 in MessageQueue::_call_function (this=0x5555602b2880, p_callable=..., p_args=0x7fffe62b8050, p_argcount=1, p_show_error=false) at core/object/message_queue.cpp:229
#45 0x000055555c0b1cef in MessageQueue::flush (this=0x5555602b2880) at core/object/message_queue.cpp:275
#46 0x000055555a0a53aa in SceneTree::physics_process (this=0x555563bda020, p_time=0.016666666666666666) at scene/main/scene_tree.cpp:420
#47 0x0000555557ab1dea in Main::iteration () at main/main.cpp:2855
#48 0x0000555557a5a87b in OS_LinuxBSD::run (this=0x7fffffffd840) at platform/linuxbsd/os_linuxbsd.cpp:537
#49 0x0000555557a55250 in main (argc=4, argv=0x7fffffffdd68) at platform/linuxbsd/godot_linuxbsd.cpp:72

I've noticed there's a mention of instance shader uniforms, so I commented out a line in the codebase that uses that.
Now the crash occurs exactly the same way, but the output is a bit different:
Thread 1 "godot.linuxbsd." received signal SIGSEGV, Segmentation fault.
0x000055555c10ddaa in StringName::StringName (this=<error reading variable: Cannot access memory at address 0x7fffff7feff8>, p_name=<error reading variable: Cannot access memory at address 0x7fffff7feff0>, p_static=<error reading variable: Cannot access memory at address 0x7fffff7fefec>) at core/string/string_name.cpp:200
200     StringName::StringName(const char *p_name, bool p_static) {
(gdb) bt
#0  0x000055555c10ddaa in StringName::StringName (this=<error reading variable: Cannot access memory at address 0x7fffff7feff8>, p_name=<error reading variable: Cannot access memory at address 0x7fffff7feff0>, p_static=<error reading variable: Cannot access memory at address 0x7fffff7fefec>)
    at core/string/string_name.cpp:200
#1  0x000055555983dd4d in ShaderLanguage::VaryingFunctionNames::VaryingFunctionNames (this=0x7fffff7ff348) at ./servers/rendering/shader_language.h:346
#2  0x000055555983dedb in ShaderLanguage::ShaderCompileInfo::ShaderCompileInfo (this=0x7fffff7ff300) at ./servers/rendering/shader_language.h:1113
#3  0x000055555b486073 in ShaderCompiler::compile (this=0x5555619a1418, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffff7ff640, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1317
#4  0x000055555b5e3fc9 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x5555797c4090, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#5  0x000055555b61ebfa in RendererRD::MaterialStorage::shader_set_code (this=0x5555613bd0a0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#6  0x000055555b477c7f in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffb8336d48) at ./core/templates/command_queue_mt.h:322
#7  0x000055555b428e49 in CommandQueueMT::_flush (this=0x5555612f6150) at ./core/templates/command_queue_mt.h:373
#8  0x000055555b428ede in CommandQueueMT::flush_if_pending (this=0x5555612f6150) at ./core/templates/command_queue_mt.h:404
#9  0x000055555b440cf6 in RenderingServerDefault::global_shader_uniform_get_type (this=0x5555612f5f10, p1=...) at servers/rendering/rendering_server_default.h:916
#10 0x000055555b486010 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#11 0x000055555b4b85ca in ShaderLanguage::_parse_shader (this=0x5555619a1418, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8292
#12 0x000055555b4c54b9 in ShaderLanguage::compile (this=0x5555619a1418, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9677
#13 0x000055555b486125 in ShaderCompiler::compile (this=0x5555619a1418, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffff800650, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#14 0x000055555b5e3fc9 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x5555797c4090, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#15 0x000055555b61ebfa in RendererRD::MaterialStorage::shader_set_code (this=0x5555613bd0a0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#16 0x000055555b477c7f in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffb8336d48) at ./core/templates/command_queue_mt.h:322
#17 0x000055555b428e49 in CommandQueueMT::_flush (this=0x5555612f6150) at ./core/templates/command_queue_mt.h:373
#18 0x000055555b428ede in CommandQueueMT::flush_if_pending (this=0x5555612f6150) at ./core/templates/command_queue_mt.h:404
#19 0x000055555b440cf6 in RenderingServerDefault::global_shader_uniform_get_type (this=0x5555612f5f10, p1=...) at servers/rendering/rendering_server_default.h:916
#20 0x000055555b486010 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#21 0x000055555b4b85ca in ShaderLanguage::_parse_shader (this=0x5555619a1418, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8292
#22 0x000055555b4c54b9 in ShaderLanguage::compile (this=0x5555619a1418, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9677
#23 0x000055555b486125 in ShaderCompiler::compile (this=0x5555619a1418, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffff801660, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#24 0x000055555b5e3fc9 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x5555797c4090, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#25 0x000055555b61ebfa in RendererRD::MaterialStorage::shader_set_code (this=0x5555613bd0a0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#26 0x000055555b477c7f in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffb8336d48) at ./core/templates/command_queue_mt.h:322
#27 0x000055555b428e49 in CommandQueueMT::_flush (this=0x5555612f6150) at ./core/templates/command_queue_mt.h:373
#28 0x000055555b428ede in CommandQueueMT::flush_if_pending (this=0x5555612f6150) at ./core/templates/command_queue_mt.h:404
#29 0x000055555b440cf6 in RenderingServerDefault::global_shader_uniform_get_type (this=0x5555612f5f10, p1=...) at servers/rendering/rendering_server_default.h:916
#30 0x000055555b486010 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#31 0x000055555b4b85ca in ShaderLanguage::_parse_shader (this=0x5555619a1418, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8292
#32 0x000055555b4c54b9 in ShaderLanguage::compile (this=0x5555619a1418, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9677
#33 0x000055555b486125 in ShaderCompiler::compile (this=0x5555619a1418, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffff802670, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#34 0x000055555b5e3fc9 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x5555797c4090, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#35 0x000055555b61ebfa in RendererRD::MaterialStorage::shader_set_code (this=0x5555613bd0a0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#36 0x000055555b477c7f in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffb8336d48) at ./core/templates/command_queue_mt.h:322
#37 0x000055555b428e49 in CommandQueueMT::_flush (this=0x5555612f6150) at ./core/templates/command_queue_mt.h:373
#38 0x000055555b428ede in CommandQueueMT::flush_if_pending (this=0x5555612f6150) at ./core/templates/command_queue_mt.h:404
#39 0x000055555b440cf6 in RenderingServerDefault::global_shader_uniform_get_type (this=0x5555612f5f10, p1=...) at servers/rendering/rendering_server_default.h:916
#40 0x000055555b486010 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#41 0x000055555b4b85ca in ShaderLanguage::_parse_shader (this=0x5555619a1418, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8292
#42 0x000055555b4c54b9 in ShaderLanguage::compile (this=0x5555619a1418, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9677
#43 0x000055555b486125 in ShaderCompiler::compile (this=0x5555619a1418, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffff803680, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#44 0x000055555b5e3fc9 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x5555797c4090, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#45 0x000055555b61ebfa in RendererRD::MaterialStorage::shader_set_code (this=0x5555613bd0a0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#46 0x000055555b477c7f in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffb8336d48) at ./core/templates/command_queue_mt.h:322
#47 0x000055555b428e49 in CommandQueueMT::_flush (this=0x5555612f6150) at ./core/templates/command_queue_mt.h:373
#48 0x000055555b428ede in CommandQueueMT::flush_if_pending (this=0x5555612f6150) at ./core/templates/command_queue_mt.h:404
#49 0x000055555b440cf6 in RenderingServerDefault::global_shader_uniform_get_type (this=0x5555612f5f10, p1=...) at servers/rendering/rendering_server_default.h:916
(...)

This goes on for 20k lines now. Here's the full thing: full backtrace.zip
I've also tried doing an completely clean git repo clone, as in the past that has proven to "solve" some issues that nothing else helped with. How does that work - I have absolutely no idea, but it does. I guess sometimes a repo clone on my disk just gets cursed and I need to get a clean one, checkout where I was and keep going :stuck_out_tongue_closed_eyes:
So this is where I am at the moment.
Steps to reproduce
If you'd like to test my project on your own (unfortunately it's definitely not a minimal one - clean repo clone is 2.2 GB right now), here's how:

Clone my project repo:
https://codeberg.org/unfa/Liblast
Initialize LFS: git lfs install (it seems there is no need to do git lfs pull but it won't hurt).
Check out server-refactor branch
Try to open the project located in Liblast/Game in the Godot editor.

@unfa The second crashdump is a stack memory error.  Considering your stack in your zip is 20392 frames long... it's likely your program runs out of stack memory and segfaults.   The first crashdump would be well served to provide a crashdump of an asan build.  I think @Calinou provides asan editor builds.  That segfault could be anything, but with asan at least we can see what type of memory error it is as asan will quarantine memory regions and instrument every load and store.  It can then report the type of memory error, place of allocation, free, etc.  A bunch of useful things.

#1  0x000055555b428e49 in CommandQueueMT::_flush (this=0x5555612f21d0) at ./core/templates/command_queue_mt.h:373
#2  0x000055555b428ede in CommandQueueMT::flush_if_pending (this=0x5555612f21d0) at ./core/templates/command_queue_mt.h:404
#3  0x000055555b440cf6 in RenderingServerDefault::global_shader_uniform_get_type (this=0x5555612f1f90, p1=...) at servers/rendering/rendering_server_default.h:916
#4  0x000055555b486010 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#5  0x000055555b4b85ca in ShaderLanguage::_parse_shader (this=0x5555619f0288, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8292
#6  0x000055555b4c54b9 in ShaderLanguage::compile (this=0x5555619f0288, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9677
#7  0x000055555b486125 in ShaderCompiler::compile (this=0x5555619f0288, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffffffc7a0, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#8  0x000055555b5e3fc9 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557bb35710, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#9  0x000055555b61ebfa in RendererRD::MaterialStorage::shader_set_code (this=0x5555613b9780, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#10 0x000055555b477c7f in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffb81d1b20) at ./core/templates/command_queue_mt.h:322
#11 0x000055555b428e49 in CommandQueueMT::_flush (this=0x5555612f21d0) at ./core/templates/command_queue_mt.h:373
#12 0x000055555b428ede in CommandQueueMT::flush_if_pending (this=0x5555612f21d0) at ./core/templates/command_queue_mt.h:404
#13 0x000055555b44103d in RenderingServerDefault::free (this=0x5555612f1f90, p_rid=...) at servers/rendering/rendering_server_default.h:931
#14 0x000055555a0127db in CanvasItem::~CanvasItem (this=0x5555755bb370, __in_chrg=<optimized out>) at scene/main/canvas_item.cpp:1183

I'm not up to date with 4.X, but it looks odd that canvas item destructor CanvasItem::~CanvasItem eventually calls through to RendererRD::MaterialStorage::shader_set_code that really seems not correct.

Which graphics library are you using? amdvlk or vulkan-radeon?
I tried to replicate the crash in Arch Linux and I'm not able to at the moment.

I was able to reproduce the issue. Here's the ASAN report: asan_report.txt
The reports shows an use-after-free, but in particular what I'm seeing with gdb is that there's a CommandBase object that seems to get overwritten at some point. It's function pointer at cmd->call gets zeroed out and that's what's causing a segfault:
Thread 1 "godot-master" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) up
#1  0x0000555555f4f9ac in CommandQueueMT::_flush (this=0x55556287fac0) at ./core/templates/command_queue_mt.h:373
373                             cmd->call(); //execute the function

Your asan report looks like a standard use after free, combined with multithreading issue and focus there...  Use after free can continue on in certain circumstances and continue to cause more memory corruption which can lead to weird things happening, so start with fixing the use after free memory error reported by asan before debugging further with gdb in non-asan builds.
From your asan attached report:
1): The engine is allocing a GradientTexture1D ON THREAD T50 here:  (This thread looks like it is a EditorFileSystem::scan thread).
#1 0x561ce6be6538 in Memory::alloc_static(unsigned long, bool) core/os/memory.cpp:75
    #2 0x561ce6be6456 in operator new(unsigned long, char const*) core/os/memory.cpp:40
    #3 0x561cde94889a in Object* ClassDB::creator<GradientTexture1D>() (/opt/godot-master/bin/godot.linuxbsd.opt.tools.64.san+0xa44389a)
    #4 0x561ce825cbbb in ClassDB::instantiate(StringName const&) core/object/class_db.cpp:338
    #5 0x561ce1af3537 in ResourceLoaderText::load() scene/resources/resource_format_text.cpp:565

2): It is being free on the same editor scan thread (T50) here:
    #1 0x561ce6be710e in Memory::free_static(void*, bool) core/os/memory.cpp:168
    #2 0x561cd5d4dfc2 in void memdelete<Texture2D>(Texture2D*) core/os/memory.h:112
    #3 0x561cd5d44347 in Ref<Texture2D>::unref() core/object/ref_counted.h:221
    #4 0x561cd5d38f79 in Ref<Texture2D>::~Ref() core/object/ref_counted.h:233
    #5 0x561ce19a53a3 in ParticlesMaterial::~ParticlesMaterial() scene/resources/particles_material.cpp:1867

3): It is being used again on main thread (T0) here:
    #0 0x561ce203577f in GradientTexture1D::_update() scene/resources/texture.cpp:2240
    #1 0x561cd6213be7 in void call_with_variant_args_helper<__UnexistingClass>(__UnexistingClass*, void (__UnexistingClass::*)(), Variant const**, Callable::CallError&, IndexSequence<>) core/variant/binder_common.h:262
    #2 0x561cd6204492 in void call_with_variant_args_dv<__UnexistingClass>(__UnexistingClass*, void (__UnexistingClass::*)(), Variant const**, int, Callable::CallError&, Vector<Variant> const&) core/variant/binder_common.h:409
    #3 0x561cd61f0d7e in MethodBindT<>::call(Object*, Variant const**, int, Callable::CallError&) core/object/method_bind.h:320
    #4 0x561ce82cb5cd in Object::callp(StringName const&, Variant const**, int, Callable::CallError&) core/object/object.cpp:678
    #5 0x561ce74c5457 in Callable::callp(Variant const**, int, Variant&, Callable::CallError&) const core/variant/callable.cpp:62
    #6 0x561ce82ae53c in MessageQueue::_call_function(Callable const&, Variant const*, int, bool) core/object/message_queue.cpp:229
    #7 0x561ce82aef6b in MessageQueue::flush() core/object/message_queue.cpp:275

So some callable, to GradientTexture1D::_update( is queued in the MessageQueue for processing on the main thread, which is executing on the GradientTexture1D (which was already freed from the originating T50  thread).
In your particular case, it looks to be caused by something in a particles material which can at least start to point you in some direction:
#5 0x561ce19a53a3 in ParticlesMaterial::~ParticlesMaterial() scene/resources/particles_material.cpp:1867

So.... I'm almost willing to bet, this is the cause:

If this 'queue_update` API is called on an object from ANY non-main thread, and the object is destructed before the MessageQueue on the main thread is flushed (call_deferred pushes that onto this queue for processing), guess what?  Kablam...
I really have a problem with the call_deferred design, because it's really hacky and easily leads to bugs like this which hinders the ability to do multithreaded things in the engine safely.
I'm not sure what the specific fix is for this issue, but overall call_deferred should probably warm or do something when it's called from a non-main thread, or if it's used from a Resource or any reference counted object (Ref<>), increment the reference count (delays object destruction), and decrement after callable is flushed from the messagequeue.  It's always dangerous in general pushing something like an Object* into an async messagequeue which has no pointer ownership or sharing semantics.  But will be up to engine maintainers to decide how to proceed with any overall design change.

Ahhh, ok.  So digging a bit further, here is potential root source of error (still related to call_deferred)....  (This is also why thread safety is tricky to get right).
So Callable doesn't actually store (well in most cases) an Object*, but an Object ID.   Which is OK as it does a lookup to retrieve the object by ID before actually jumping to the callable exec (see below screencap).
However, the lines between the object retrieval and the exec function on the object (line 52 and line 62), are not thread-safe.  I.e. line 52 ObjectDB::get_instance(ObjectID(object)) can retrieve a valid Object* but the Object* could be freed by another thread before line 62 is executed.  (We know this particular issue has object destruction on a different thread).

The correct solution for this is not that trivial as it has implication for how Callable's work, and for how locking in the ObjectDB is done.  But, the current design is not thread-safe.  To make Callable's thread-safe, they need to ensure the lifetime of the object extends past actually executing obj->callp (line 62).

My suggestion would be to start migrating away from using raw Object* (which will continue to have dangling ref issues due to lack of any ownership semantics), and move into using something like a std::weak_ptr, which can be tested and converted into a strong reference before usage, ex before: (obj->callp) which will guarantee lifetime beyond the function call.
An async processed MessageQueue (godot's main thread message queue) would be a good example of where std::weak_ptr is a good design choice for how the queue stores the actual object pointers in it's internal callable queue.

This  comes to mind: https://github.com/godotengine/godot/pull/40764.

I think @Calinou provides asan editor builds.

I don't – https://github.com/Calinou/godot-debug-builds only contains standard debug symbols. Sanitizers require using recent compilers, which compromise support of old Linux distributions, making those binaries difficult to distribute publicly.

If this queue_update API is called on an object from ANY non-main thread, and the object is destructed before the MessageQueue on the main thread is flushed (call_deferred pushes that onto this queue for processing), guess what? Kablam...

That's just a straight up bug.  You can't synchronously destroy an object that participates in async callbacks.  You have to mark the object as "out of service, don't make any more async requests" and defer the destruction itself to get it to sort after any operations.   I think this is just another case of people using call_deferred as a cheap thread safety hack, which doesn't work unless your object has eternal (i.e. scene graph) lifetime.

Oh and regarding the excellent std::weak_ptr recommendation, you're basically just asking for call_deferred to be moved to RefCounted.   That would make actually implement the current rules that the Object's lifetime has to be ensured if it is used across threads.    That makes tons of sense to me, but for some design reason, call_deferred is allowed on Object.   It would be helpful if an architect could explain why that is important.  Somewhere there might be a zillion non counted objects that need it?

BTW, I've reverted a problematic commit in my project that seems to be the first bad one (after the codebase) and it didn't fix the problem, but the backtrace looks different:
[Thread 0x7fffb0ff96c0 (LWP 1708026) exited]

Thread 1 "godot.linuxbsd." received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000055555b428e49 in CommandQueueMT::_flush (this=0x5555612f8a30) at ./core/templates/command_queue_mt.h:373
#2  0x000055555b428ede in CommandQueueMT::flush_if_pending (this=0x5555612f8a30) at ./core/templates/command_queue_mt.h:404
#3  0x000055555b440cf6 in RenderingServerDefault::global_shader_uniform_get_type (this=0x5555612f87f0, p1=...) at servers/rendering/rendering_server_default.h:916
#4  0x000055555b486010 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#5  0x000055555b4b85ca in ShaderLanguage::_parse_shader (this=0x5555619a63b8, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8292
#6  0x000055555b4c54b9 in ShaderLanguage::compile (this=0x5555619a63b8, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9677
#7  0x000055555b486125 in ShaderCompiler::compile (this=0x5555619a63b8, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffffffc7a0, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#8  0x000055555b5e3fc9 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557a485b00, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#9  0x000055555b61ebfa in RendererRD::MaterialStorage::shader_set_code (this=0x555561333580, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#10 0x000055555b477c7f in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffb817ce90) at ./core/templates/command_queue_mt.h:322
#11 0x000055555b428e49 in CommandQueueMT::_flush (this=0x5555612f8a30) at ./core/templates/command_queue_mt.h:373
#12 0x000055555b428ede in CommandQueueMT::flush_if_pending (this=0x5555612f8a30) at ./core/templates/command_queue_mt.h:404
#13 0x000055555b44103d in RenderingServerDefault::free (this=0x5555612f87f0, p_rid=...) at servers/rendering/rendering_server_default.h:931
#14 0x000055555a0127db in CanvasItem::~CanvasItem (this=0x55557577fea0, __in_chrg=<optimized out>) at scene/main/canvas_item.cpp:1183
#15 0x00005555582dd348 in Control::~Control (this=0x55557577fea0, __in_chrg=<optimized out>) at ./scene/gui/control.h:45
#16 0x000055555a337278 in Range::~Range (this=0x55557577fea0, __in_chrg=<optimized out>) at scene/gui/range.cpp:335
#17 0x000055555a332de4 in ProgressBar::~ProgressBar (this=0x55557577fea0, __in_chrg=<optimized out>) at scene/gui/progress_bar.h:36
#18 0x0000555557f2033f in memdelete<Node> (p_class=0x55557577fea0) at ./core/os/memory.h:109
--Type <RET> for more, q to quit, c to continue without paging--
#19 0x000055555a06ace7 in Node::_notification (this=0x5555757806e0, p_notification=1) at scene/main/node.cpp:169
#20 0x0000555557c1345c in Node::_notificationv (this=0x5555757806e0, p_notification=1, p_reversed=true) at scene/main/node.h:45
#21 0x00005555582db2ad in CanvasItem::_notificationv (this=0x5555757806e0, p_notification=1, p_reversed=true) at ./scene/main/canvas_item.h:45
#22 0x00005555582db9e9 in Control::_notificationv (this=0x5555757806e0, p_notification=1, p_reversed=true) at scene/gui/control.h:46
#23 0x000055555c0b7bbf in Object::notification (this=0x5555757806e0, p_notification=1, p_reversed=true) at core/object/object.cpp:735
#24 0x000055555c0b56bd in Object::_predelete (this=0x5555757806e0) at core/object/object.cpp:195
#25 0x000055555c0c1df3 in predelete_handler (p_object=0x5555757806e0) at core/object/object.cpp:1777
#26 0x0000555557f2031f in memdelete<Node> (p_class=0x5555757806e0) at ./core/os/memory.h:105
#27 0x000055555a06ace7 in Node::_notification (this=0x555574496a50, p_notification=1) at scene/main/node.cpp:169
#28 0x0000555557c1345c in Node::_notificationv (this=0x555574496a50, p_notification=1, p_reversed=true) at scene/main/node.h:45
#29 0x00005555582db2ad in CanvasItem::_notificationv (this=0x555574496a50, p_notification=1, p_reversed=true) at ./scene/main/canvas_item.h:45
#30 0x00005555582db9e9 in Control::_notificationv (this=0x555574496a50, p_notification=1, p_reversed=true) at scene/gui/control.h:46
#31 0x00005555582dc239 in Container::_notificationv (this=0x555574496a50, p_notification=1, p_reversed=true) at ./scene/gui/container.h:37
#32 0x00005555582dc975 in BoxContainer::_notificationv (this=0x555574496a50, p_notification=1, p_reversed=true) at ./scene/gui/box_container.h:37
#33 0x00005555582dd263 in HBoxContainer::_notificationv (this=0x555574496a50, p_notification=1, p_reversed=true) at ./scene/gui/box_container.h:72
#34 0x000055555c0b7bbf in Object::notification (this=0x555574496a50, p_notification=1, p_reversed=true) at core/object/object.cpp:735
#35 0x000055555c0b56bd in Object::_predelete (this=0x555574496a50) at core/object/object.cpp:195
#36 0x000055555c0c1df3 in predelete_handler (p_object=0x555574496a50) at core/object/object.cpp:1777
#37 0x000055555922dbe3 in memdelete<HBoxContainer> (p_class=0x555574496a50) at ./core/os/memory.h:105
#38 0x000055555922a9b0 in BackgroundProgress::_end_task (this=0x555569a47020, p_task=...) at editor/progress_dialog.cpp:94
#39 0x0000555557ad1d21 in call_with_variant_args_helper<__UnexistingClass, String const&, 0ul> (p_instance=0x555569a47020,
    p_method=(void (__UnexistingClass::*)(__UnexistingClass * const, const String &)) 0x55555922a8d2 <BackgroundProgress::_end_task(String const&)>, p_args=0x7fffffffd2a0, r_error=...) at ./core/variant/binder_common.h:262
#40 0x0000555557ad190e in call_with_variant_args_dv<__UnexistingClass, String const&> (p_instance=0x555569a47020,
    p_method=(void (__UnexistingClass::*)(__UnexistingClass * const, const String &)) 0x55555922a8d2 <BackgroundProgress::_end_task(String const&)>, p_args=0x7fffffffd4b0, p_argcount=1, r_error=..., default_values=...)
    at ./core/variant/binder_common.h:409
#41 0x0000555557ad14c2 in MethodBindT<String const&>::call (this=0x555569a47c60, p_object=0x555569a47020, p_args=0x7fffffffd4b0, p_arg_count=1, r_error=...) at ./core/object/method_bind.h:320
#42 0x000055555c0b77fb in Object::callp (this=0x555569a47020, p_method=..., p_args=0x7fffffffd4b0, p_argcount=1, r_error=...) at core/object/object.cpp:678
#43 0x000055555bd77c9c in Callable::callp (this=0x7fffe62b8038, p_arguments=0x7fffffffd4b0, p_argcount=1, r_return_value=..., r_call_error=...) at core/variant/callable.cpp:62
#44 0x000055555c0b19a0 in MessageQueue::_call_function (this=0x5555602b2880, p_callable=..., p_args=0x7fffe62b8050, p_argcount=1, p_show_error=false) at core/object/message_queue.cpp:229
#45 0x000055555c0b1cef in MessageQueue::flush (this=0x5555602b2880) at core/object/message_queue.cpp:275
#46 0x000055555a0a53aa in SceneTree::physics_process (this=0x555563bcdbb0, p_time=0.016666666666666666) at scene/main/scene_tree.cpp:420
#47 0x0000555557ab1dea in Main::iteration () at main/main.cpp:2855
#48 0x0000555557a5a87b in OS_LinuxBSD::run (this=0x7fffffffd840) at platform/linuxbsd/os_linuxbsd.cpp:537
(...)

I've gone back to the last known good commit in my project and branched off form there, hoping I can do some work done before this is fixed.
I've compiled Godot from 106b6805018649b13da9e9508e80611f62ed660a and carried on.
Then I have had a random crash while working on some UI elements, I am not sure if it's related, but a lot in this backtrace seems familiar:
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.alpha.custom_build (106b6805018649b13da9e9508e80611f62ed660a)
Dumping the backtrace. Please include this when reporting the bug on: https://github.com/godotengine/godot/issues
[1] /usr/lib/libc.so.6(+0x38a40) [0x7ffff7ac6a40] (??:0)
[2] CompressedTexture2D::~CompressedTexture2D() (??:0)
[3] void memdelete<RefCounted>(RefCounted*) (??:0)
[4] Variant::_clear_internal() (??:0)
[5] Variant::clear() (??:0)
[6] Variant::~Variant() (??:0)
[7] CowData<Variant>::_unref(void*) (??:0)
[8] CowData<Variant>::~CowData() (??:0)
[9] Vector<Variant>::~Vector() (??:0)
[10] KeyValue<DisplayServer::CursorShape, Vector<Variant> >::~KeyValue() (??:0)
[11] HashMapElement<DisplayServer::CursorShape, Vector<Variant> >::~HashMapElement() (??:0)
[12] void memdelete<HashMapElement<DisplayServer::CursorShape, Vector<Variant> > >(HashMapElement<DisplayServer::CursorShape, Vector<Variant> >*) (??:0)
[13] DefaultTypedAllocator<HashMapElement<DisplayServer::CursorShape, Vector<Variant> > >::delete_allocation(HashMapElement<DisplayServer::CursorShape, Vector<Variant> >*) (??:0)
[14] HashMap<DisplayServer::CursorShape, Vector<Variant>, HashMapHasherDefault, HashMapComparatorDefault<DisplayServer::CursorShape>, DefaultTypedAllocator<HashMapElement<DisplayServer::CursorShape, Vector<Variant> > > >::clear() (??:0)
[15] HashMap<DisplayServer::CursorShape, Vector<Variant>, HashMapHasherDefault, HashMapComparatorDefault<DisplayServer::CursorShape>, DefaultTypedAllocator<HashMapElement<DisplayServer::CursorShape, Vector<Variant> > > >::~HashMap() (??:0)
[16] DisplayServerX11::~DisplayServerX11() (??:0)
[17] void memdelete<DisplayServer>(DisplayServer*) (??:0)
[18] finalize_display() (??:0)
[19] Main::cleanup(bool) (??:0)
[20] /data/Projects/Games/Liblast/Repo/Godot/godot-repo/bin/godot.linuxbsd.tools.64(main+0x191) [0x555557a5525a] (??:0)
[21] /usr/lib/libc.so.6(+0x232d0) [0x7ffff7ab12d0] (??:0)
[22] /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7ffff7ab138a] (??:0)
[23] /data/Projects/Games/Liblast/Repo/Godot/godot-repo/bin/godot.linuxbsd.tools.64(_start+0x25) [0x555557a54ff5] (??:0)
-- END OF BACKTRACE --
================================================================
(gdb) bt
#0  0x00007ffff7b17994 in pthread_mutex_lock () from /usr/lib/libc.so.6
#1  0x0000555557a6276a in __gthread_mutex_lock (__mutex=0x62006100720255) at /usr/include/c++/12.1.1/x86_64-pc-linux-gnu/bits/gthr-default.h:749
#2  0x0000555557a627ba in __gthread_recursive_mutex_lock (__mutex=0x62006100720255) at /usr/include/c++/12.1.1/x86_64-pc-linux-gnu/bits/gthr-default.h:811
#3  0x0000555557a627ee in std::recursive_mutex::lock (this=0x62006100720255) at /usr/include/c++/12.1.1/mutex:108
#4  0x000055555a0adb56 in MutexImpl<std::recursive_mutex>::lock (this=0x62006100720255) at ./core/os/mutex.h:47
#5  MutexLock<MutexImpl<std::recursive_mutex> >::MutexLock (p_mutex=..., this=<optimized out>) at ./core/os/mutex.h:66
#6  SceneTree::queue_delete (this=0x62006100720065, p_object=0x55557d3cd500) at scene/main/scene_tree.cpp:1075
#7  0x000055555a07f622 in Node::queue_delete (this=0x55557d3cd500) at scene/main/node.cpp:2628
#8  0x000055555a0d9344 in Viewport::_gui_cancel_tooltip (this=0x555563329a00) at scene/main/viewport.cpp:1127
#9  0x000055555a0db2b7 in Viewport::_gui_input_event (this=0x555563329a00, p_event=...) at scene/main/viewport.cpp:1552
#10 0x000055555a0e2a15 in Viewport::push_input (this=0x555563329a00, p_event=..., p_local_coords=false) at scene/main/viewport.cpp:2746
#11 0x000055555a124667 in Window::_window_input (this=0x555563329a00, p_ev=...) at scene/main/window.cpp:1045
#12 0x000055555a144023 in call_with_variant_args_helper<Window, Ref<InputEvent> const&, 0ul> (p_instance=0x555563329a00, p_method=(void (Window::*)(Window * const, const Ref<InputEvent> &)) 0x55555a1244ba <Window::_window_input(Ref<InputEvent> const&)>, p_args=0x7fffffffd248, r_error=...)
    at ./core/variant/binder_common.h:262
#13 0x000055555a1410f9 in call_with_variant_args<Window, Ref<InputEvent> const&> (p_instance=0x555563329a00, p_method=(void (Window::*)(Window * const, const Ref<InputEvent> &)) 0x55555a1244ba <Window::_window_input(Ref<InputEvent> const&)>, p_args=0x7fffffffd248, p_argcount=1, r_error=...)
    at ./core/variant/binder_common.h:376
#14 0x000055555a13d2e8 in CallableCustomMethodPointer<Window, Ref<InputEvent> const&>::call (this=0x5555705789b0, p_arguments=0x7fffffffd248, p_argcount=1, r_return_value=..., r_call_error=...) at ./core/object/callable_method_pointer.h:104
#15 0x000055555bd7d2b1 in Callable::callp (this=0x7fffffffd290, p_arguments=0x7fffffffd248, p_argcount=1, r_return_value=..., r_call_error=...) at core/variant/callable.cpp:50
#16 0x0000555557a75d36 in DisplayServerX11::_dispatch_input_event (this=0x5555606e4f00, p_event=...) at platform/linuxbsd/display_server_x11.cpp:3184
#17 0x0000555557a75a9d in DisplayServerX11::_dispatch_input_events (p_event=...) at platform/linuxbsd/display_server_x11.cpp:3155
#18 0x000055555bd1efdb in Input::_parse_input_event_impl (this=0x55556062a9d0, p_event=..., p_is_emulated=false) at core/input/input.cpp:663
#19 0x000055555bd20507 in Input::flush_buffered_events (this=0x55556062a9d0) at core/input/input.cpp:888
#20 0x0000555557a7a94c in DisplayServerX11::process_events (this=0x5555606e4f00) at platform/linuxbsd/display_server_x11.cpp:4173
#21 0x0000555557a5a887 in OS_LinuxBSD::run (this=0x7fffffffd840) at platform/linuxbsd/os_linuxbsd.cpp:536
#22 0x0000555557a55250 in main (argc=4, argv=0x7fffffffdd68) at platform/linuxbsd/godot_linuxbsd.cpp:72

I've hit the exact stacktrace above (https://github.com/godotengine/godot/issues/64190#issuecomment-1211419628) several times in Godot 4. I'm not able to consistently repro. https://github.com/godotengine/godot/issues/63555 and https://github.com/godotengine/godot/issues/59798 also mention Viewport::_gui_cancel_tooltip

TL;DR
One can open the project in Godot editor from the last good commit, then check out the bad commit, reload scenes and scripts and carry on. The crash will only happen after the project is fully unloaded and loaded again.
Wider context:
To not be completely blocked in my project≤ I've branched off from the last good commit, and carried on with some other work.
I've tried merging the rest of the problematic branch back into my new one to see if this problem will persist.
It did, but I've noticed something interesting - the crash occurred only after I've manually reloaded the whole project.
When I've just  finished my merge at first Godot asked to reload scenes that were changed on disk, I did that and was able to keep working on the project and run the game.
Only after I've reloaded the project the crash has happened. So there is something that's being called only on initial project load that causes the crash. This seems to me like something rather simple, as it clearly is possible to still work on the project and run it if the initial loading is skipped. It seems that I could "work this around" by always checking my known last good commit, opening the project in Godot and then checkout the branch to update the project.

After I rolled back my merge with git reset --soft HEAD~1 and then did git rest --hard HEAD I still have a crash on project load, but it's a bit different:
#0  0x000055555bde9b50 in StringName::StringName (this=<error reading variable: Cannot access memory at address 0x7fffff7fefe8>, p_name=<error reading variable: Cannot access memory at address 0x7fffff7fefe0>,
    p_static=<error reading variable: Cannot access memory at address 0x7fffff7fefdc>) at core/string/string_name.cpp:200
#1  0x00005555595fddfe in ShaderLanguage::VaryingFunctionNames::VaryingFunctionNames (this=0x7fffff7ff348) at ./servers/rendering/shader_language.h:346
#2  0x00005555595fdf87 in ShaderLanguage::ShaderCompileInfo::ShaderCompileInfo (this=0x7fffff7ff300) at ./servers/rendering/shader_language.h:1113
#3  0x000055555b197ba5 in ShaderCompiler::compile (this=0x555561574d48, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffff7ff6a0, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1317
#4  0x000055555b2eb413 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557ad72040, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#5  0x000055555b3244a5 in RendererRD::MaterialStorage::shader_set_code (this=0x5555610a5ff0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#6  0x000055555b189ae3 in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffbc14cc78) at ./core/templates/command_queue_mt.h:322
#7  0x000055555b13b5b9 in CommandQueueMT::_flush (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:373
#8  0x000055555b13b646 in CommandQueueMT::flush_if_pending (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:404
#9  0x000055555b15304b in RenderingServerDefault::global_shader_uniform_get_type (this=0x555560fca7c0, p1=...) at servers/rendering/rendering_server_default.h:916
#10 0x000055555b197b42 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#11 0x000055555b1c97a4 in ShaderLanguage::_parse_shader (this=0x555561574d48, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8330
#12 0x000055555b1d6417 in ShaderLanguage::compile (this=0x555561574d48, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9715
#13 0x000055555b197c57 in ShaderCompiler::compile (this=0x555561574d48, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffff800710, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#14 0x000055555b2eb413 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557ad72040, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#15 0x000055555b3244a5 in RendererRD::MaterialStorage::shader_set_code (this=0x5555610a5ff0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#16 0x000055555b189ae3 in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffbc14cc78) at ./core/templates/command_queue_mt.h:322
#17 0x000055555b13b5b9 in CommandQueueMT::_flush (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:373
#18 0x000055555b13b646 in CommandQueueMT::flush_if_pending (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:404
#19 0x000055555b15304b in RenderingServerDefault::global_shader_uniform_get_type (this=0x555560fca7c0, p1=...) at servers/rendering/rendering_server_default.h:916
#20 0x000055555b197b42 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#21 0x000055555b1c97a4 in ShaderLanguage::_parse_shader (this=0x555561574d48, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8330
#22 0x000055555b1d6417 in ShaderLanguage::compile (this=0x555561574d48, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9715
#23 0x000055555b197c57 in ShaderCompiler::compile (this=0x555561574d48, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffff801780, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#24 0x000055555b2eb413 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557ad72040, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#25 0x000055555b3244a5 in RendererRD::MaterialStorage::shader_set_code (this=0x5555610a5ff0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#26 0x000055555b189ae3 in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffbc14cc78) at ./core/templates/command_queue_mt.h:322
#27 0x000055555b13b5b9 in CommandQueueMT::_flush (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:373
#28 0x000055555b13b646 in CommandQueueMT::flush_if_pending (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:404
#29 0x000055555b15304b in RenderingServerDefault::global_shader_uniform_get_type (this=0x555560fca7c0, p1=...) at servers/rendering/rendering_server_default.h:916
#30 0x000055555b197b42 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#31 0x000055555b1c97a4 in ShaderLanguage::_parse_shader (this=0x555561574d48, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8330
#32 0x000055555b1d6417 in ShaderLanguage::compile (this=0x555561574d48, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9715
#33 0x000055555b197c57 in ShaderCompiler::compile (this=0x555561574d48, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffff8027f0, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#34 0x000055555b2eb413 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557ad72040, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#35 0x000055555b3244a5 in RendererRD::MaterialStorage::shader_set_code (this=0x5555610a5ff0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#36 0x000055555b189ae3 in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffbc14cc78) at ./core/templates/command_queue_mt.h:322
#37 0x000055555b13b5b9 in CommandQueueMT::_flush (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:373
#38 0x000055555b13b646 in CommandQueueMT::flush_if_pending (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:404
#39 0x000055555b15304b in RenderingServerDefault::global_shader_uniform_get_type (this=0x555560fca7c0, p1=...) at servers/rendering/rendering_server_default.h:916
#40 0x000055555b197b42 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#41 0x000055555b1c97a4 in ShaderLanguage::_parse_shader (this=0x555561574d48, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8330
#42 0x000055555b1d6417 in ShaderLanguage::compile (this=0x555561574d48, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9715
#43 0x000055555b197c57 in ShaderCompiler::compile (this=0x555561574d48, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffff803860, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#44 0x000055555b2eb413 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557ad72040, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#45 0x000055555b3244a5 in RendererRD::MaterialStorage::shader_set_code (this=0x5555610a5ff0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#46 0x000055555b189ae3 in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffbc14cc78) at ./core/templates/command_queue_mt.h:322
#47 0x000055555b13b5b9 in CommandQueueMT::_flush (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:373
#48 0x000055555b13b646 in CommandQueueMT::flush_if_pending (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:404
#49 0x000055555b15304b in RenderingServerDefault::global_shader_uniform_get_type (this=0x555560fca7c0, p1=...) at servers/rendering/rendering_server_default.h:916

This goes on for 20k lines and ends with:
#19894 0x000055555b2eb413 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557ad72040, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#19895 0x000055555b3244a5 in RendererRD::MaterialStorage::shader_set_code (this=0x5555610a5ff0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#19896 0x000055555b189ae3 in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffbc14cc78) at ./core/templates/command_queue_mt.h:322
#19897 0x000055555b13b5b9 in CommandQueueMT::_flush (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:373
#19898 0x000055555b13b646 in CommandQueueMT::flush_if_pending (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:404
#19899 0x000055555b15304b in RenderingServerDefault::global_shader_uniform_get_type (this=0x555560fca7c0, p1=...) at servers/rendering/rendering_server_default.h:916
#19900 0x000055555b197b42 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#19901 0x000055555b1c97a4 in ShaderLanguage::_parse_shader (this=0x555561574d48, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8330
#19902 0x000055555b1d6417 in ShaderLanguage::compile (this=0x555561574d48, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9715
#19903 0x000055555b197c57 in ShaderCompiler::compile (this=0x555561574d48, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffffffbd40, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#19904 0x000055555b2eb413 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557ad72040, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#19905 0x000055555b3244a5 in RendererRD::MaterialStorage::shader_set_code (this=0x5555610a5ff0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#19906 0x000055555b189ae3 in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffbc14cc78) at ./core/templates/command_queue_mt.h:322
#19907 0x000055555b13b5b9 in CommandQueueMT::_flush (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:373
#19908 0x000055555b13b646 in CommandQueueMT::flush_if_pending (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:404
#19909 0x000055555b15304b in RenderingServerDefault::global_shader_uniform_get_type (this=0x555560fca7c0, p1=...) at servers/rendering/rendering_server_default.h:916
#19910 0x000055555b197b42 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1312
#19911 0x000055555b1c97a4 in ShaderLanguage::_parse_shader (this=0x555561574d48, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8330
#19912 0x000055555b1d6417 in ShaderLanguage::compile (this=0x555561574d48, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9715
#19913 0x000055555b197c57 in ShaderCompiler::compile (this=0x555561574d48, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffffffcdb0, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#19914 0x000055555b2eb413 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557ad72040, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#19915 0x000055555b3244a5 in RendererRD::MaterialStorage::shader_set_code (this=0x5555610a5ff0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#19916 0x000055555b189ae3 in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffbc14cc78) at ./core/templates/command_queue_mt.h:322
#19917 0x000055555b13b5b9 in CommandQueueMT::_flush (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:373
#19918 0x000055555b13b646 in CommandQueueMT::flush_if_pending (this=0x555560fcaa00) at ./core/templates/command_queue_mt.h:404
#19919 0x000055555b13d965 in RenderingServerDefault::material_set_shader (this=0x555560fca7c0, p1=..., p2=...) at servers/rendering/rendering_server_default.h:242
#19920 0x000055555a89a10f in BaseMaterial3D::_update_shader (this=0x7fffbc0aa940) at scene/resources/material.cpp:1438
#19921 0x000055555a89aab9 in BaseMaterial3D::flush_changes () at scene/resources/material.cpp:1445
#19922 0x0000555559e1bbf8 in SceneTree::_call_idle_callbacks (this=0x555563fd6330) at scene/main/scene_tree.cpp:1344
#19923 0x0000555559e13c07 in SceneTree::process (this=0x555563fd6330, p_time=0.016719999999999999) at scene/main/scene_tree.cpp:500
#19924 0x0000555557940bed in Main::iteration () at main/main.cpp:2885
#19925 0x00005555578f5dce in OS_LinuxBSD::run (this=0x7fffffffd780) at platform/linuxbsd/os_linuxbsd.cpp:540
#19926 0x00005555578f1260 in main (argc=4, argv=0x7fffffffdca8) at platform/linuxbsd/godot_linuxbsd.cpp:72

I guess we can see where this endless loop has started.
Is it #19921 0x000055555a89aab9 in BaseMaterial3D::flush_changes () at scene/resources/material.cpp:1445 ?
Is that a hint?
I wonder why this persists even though code on my disk is now rolled back...

I've moved the .godot folder hoping I could get back this branch to a working state but I still get the same crash, it just ends the loop on a different line of code:
Thread 1 "godot" received signal SIGSEGV, Segmentation fault.
0x000055555be06eac in String::operator+= (this=<error reading variable: Cannot access memory at address 0x7fffff7fefe8>, p_char=<error reading variable: Cannot access memory at address 0x7fffff7fefe4>) at core/string/ustring.cpp:583
583     core/string/ustring.cpp: No such file or directory.
(gdb) bt
#0  0x000055555be06eac in String::operator+= (this=<error reading variable: Cannot access memory at address 0x7fffff7fefe8>, p_char=<error reading variable: Cannot access memory at address 0x7fffff7fefe4>) at core/string/ustring.cpp:583
#1  0x000055555b1a03cb in ShaderLanguage::_get_token (this=0x55556148ade8) at servers/rendering/shader_language.cpp:805
#2  0x000055555b1c58c5 in ShaderLanguage::_parse_shader (this=0x55556148ade8, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:7803
#3  0x000055555b1d6417 in ShaderLanguage::compile (this=0x55556148ade8, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9715
#4  0x000055555b197c57 in ShaderCompiler::compile (this=0x55556148ade8, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffff7ffc90, p_path=..., r_gen_code=...) at servers/rendering/shader_compiler.cpp:1323
#5  0x000055555b2eb413 in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x55557611bab0, p_code=...) at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#6  0x000055555b3244a5 in RendererRD::MaterialStorage::shader_set_code (this=0x555561097fe0, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2383
#7  0x000055555b189ae3 in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffac13b558) at ./core/templates/command_queue_mt.h:322
#8  0x000055555b13b5b9 in CommandQueueMT::_flush (this=0x555560fbc970) at ./core/templates/command_queue_mt.h:373
#9  0x000055555b13b646 in CommandQueueMT::flush_if_pending (this=0x555560fbc970) at ./core/templates/command_queue_mt.h:404
#10 0x000055555b15304b in RenderingServerDefault::global_shader_uniform_get_type (this=0x555560fbc730, p1=...) at servers/rendering/rendering_server_default.h:916

Is this a crash or a freeze? I've had a freeze on project open that required xkill, so likely an infinite loop somewhere in Godot's code

I guess we can see where this endless loop has started.
Is it #19921 0x000055555a89aab9 in BaseMaterial3D::flush_changes () at scene/resources/material.cpp:1445 ?
Is that a hint?

Not sure what's wrong with BaseMaterial3D::flush_changes, but if it's calling flush recursively, try something like:
diff --git a/core/templates/command_queue_mt.h b/core/templates/command_queue_mt.h
index 7d3e31b5bc..37cdd7d1f5 100644
--- a/core/templates/command_queue_mt.h
+++ b/core/templates/command_queue_mt.h
@@ -340,9 +340,13 @@ class CommandQueueMT {
 	SyncSemaphore sync_sems[SYNC_SEMAPHORES];
 	Mutex mutex;
 	Semaphore *sync = nullptr;
+	std::atomic<bool> flushing = false;

 	template <class T>
 	T *allocate() {
+		if (flushing.load()) {
+			ERR_PRINT("aaaa!");
+		}
 		// alloc size is size+T+safeguard
 		uint32_t alloc_size = ((sizeof(T) + 8 - 1) & ~(8 - 1));
 		uint64_t size = command_mem.size();
@@ -361,6 +365,10 @@ class CommandQueueMT {

 	void _flush() {
 		lock();
+		if (flushing.load()) {
+			return;
+		}
+		flushing.store(true);

 		uint64_t read_ptr = 0;
 		uint64_t limit = command_mem.size();
@@ -378,6 +386,7 @@ class CommandQueueMT {
 		}

 		command_mem.clear();
+		flushing.store(false);
 		unlock();
 	}

Is this a crash or a freeze? I've had a freeze on project open that required xkill, so likely an infinite loop somewhere in Godot's code

I've had Godot freeze as well requiring me to -SIGKILL it, though in this case it seems an endless loop causes something to fill up and trigger a full-on crash.

@bruvzg I was unable to apply your patch:
git apply patch
error: corrupt patch at line 37

@bruvzg I've applied your patch and tested my project with it - it no longer crashes, but instead it freezes when loading the project.
btop shows the Godot editor process as sleeping.
I can interrupt it in gdb and get a backtrace, though the process did not crash - it's just frozen.
Thread 1 "godot.linuxbsd." received signal SIGINT, Interrupt.
0x00007ffff7b2e580 in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff7b2e580 in ?? () from /usr/lib/libc.so.6
#1  0x00007ffff7b34afa in pthread_mutex_lock () from /usr/lib/libc.so.6
#2  0x0000555557a6776a in __gthread_mutex_lock (__mutex=0x555560546510) at /usr/include/c++/12.1.1/x86_64-pc-linux-gnu/bits/gthr-default.h:749
#3  0x0000555557a677ba in __gthread_recursive_mutex_lock (__mutex=0x555560546510) at /usr/include/c++/12.1.1/x86_64-pc-linux-gnu/bits/gthr-default.h:811
#4  0x0000555557a677ee in std::recursive_mutex::lock (this=0x555560546510) at /usr/include/c++/12.1.1/mutex:108
#5  0x0000555557f9c643 in MutexImpl<std::recursive_mutex>::lock (this=0x555560546510) at ./core/os/mutex.h:47
#6  MutexLock<MutexImpl<std::recursive_mutex> >::MutexLock (p_mutex=..., this=<optimized out>) at ./core/os/mutex.h:66
#7  GDScriptCache::get_full_script (p_path=..., r_error=@0x7fffffffa854: OK, p_owner=...) at modules/gdscript/gdscript_cache.cpp:189
#8  0x0000555557f44717 in ResourceFormatLoaderGDScript::load (this=0x55556054bb40, p_path=..., p_original_path=..., r_error=0x5555759c5904, p_use_sub_threads=false, r_progress=0x5555759c58f8,
    p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE) at modules/gdscript/gdscript.cpp:2348
#9  0x000055555bcd1ac7 in ResourceLoader::_load (p_path=..., p_original_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE, r_error=0x5555759c5904, p_use_sub_threads=false, r_progress=0x5555759c58f8)
    at core/io/resource_loader.cpp:213
#10 0x000055555bcd21ab in ResourceLoader::_thread_load_function (p_userdata=0x5555759c58c8) at core/io/resource_loader.cpp:240
#11 0x000055555bcd3b57 in ResourceLoader::load (p_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE, r_error=0x0) at core/io/resource_loader.cpp:568
#12 0x000055555acb2eb4 in ResourceLoaderText::load (this=0x7fffffffadd0) at scene/resources/resource_format_text.cpp:480
#13 0x000055555acc13f9 in ResourceFormatLoaderText::load (this=0x55556107b990, p_path=..., p_original_path=..., r_error=0x555579427714, p_use_sub_threads=false, r_progress=0x555579427708,
    p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE) at scene/resources/resource_format_text.cpp:1568
#14 0x000055555bcd1ac7 in ResourceLoader::_load (p_path=..., p_original_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE, r_error=0x555579427714, p_use_sub_threads=false, r_progress=0x555579427708)
    at core/io/resource_loader.cpp:213
#15 0x000055555bcd21ab in ResourceLoader::_thread_load_function (p_userdata=0x5555794276d8) at core/io/resource_loader.cpp:240
#16 0x000055555bcd3b57 in ResourceLoader::load (p_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REUSE, r_error=0x0) at core/io/resource_loader.cpp:568
#17 0x000055555acb2eb4 in ResourceLoaderText::load (this=0x7fffffffb4e0) at scene/resources/resource_format_text.cpp:480
#18 0x000055555acc13f9 in ResourceFormatLoaderText::load (this=0x55556107b990, p_path=..., p_original_path=..., r_error=0x555579658aa4, p_use_sub_threads=false, r_progress=0x555579658a98,
    p_cache_mode=ResourceFormatLoader::CACHE_MODE_REPLACE) at scene/resources/resource_format_text.cpp:1568
#19 0x000055555bcd1ac7 in ResourceLoader::_load (p_path=..., p_original_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REPLACE, r_error=0x555579658aa4, p_use_sub_threads=false, r_progress=0x555579658a98)
    at core/io/resource_loader.cpp:213
#20 0x000055555bcd21ab in ResourceLoader::_thread_load_function (p_userdata=0x555579658a68) at core/io/resource_loader.cpp:240
#21 0x000055555bcd3b57 in ResourceLoader::load (p_path=..., p_type_hint=..., p_cache_mode=ResourceFormatLoader::CACHE_MODE_REPLACE, r_error=0x7fffffffba40) at core/io/resource_loader.cpp:568
#22 0x0000555558fbac44 in EditorNode::load_scene (this=0x555562fe8560, p_scene=..., p_ignore_broken_deps=false, p_set_inherited=false, p_clear_errors=true, p_force_open_imported=false, p_silent_change_tab=false)
    at editor/editor_node.cpp:3718
#23 0x0000555558fa6e26 in EditorNode::_dialog_action (this=0x555562fe8560, p_file=...) at editor/editor_node.cpp:1890
#24 0x00005555590236a0 in call_with_variant_args_helper<EditorNode, String, 0ul> (p_instance=0x555562fe8560, p_method=(void (EditorNode::*)(EditorNode * const, String)) 0x555558fa6d12 <EditorNode::_dialog_action(String)>,
    p_args=0x7fffffffc0c0, r_error=...) at ./core/variant/binder_common.h:262
#25 0x0000555559021e50 in call_with_variant_args<EditorNode, String> (p_instance=0x555562fe8560, p_method=(void (EditorNode::*)(EditorNode * const, String)) 0x555558fa6d12 <EditorNode::_dialog_action(String)>, p_args=0x7fffffffc0c0,
    p_argcount=1, r_error=...) at ./core/variant/binder_common.h:376
#26 0x000055555901bfa6 in CallableCustomMethodPointer<EditorNode, String>::call (this=0x55556b72b740, p_arguments=0x7fffffffc0c0, p_argcount=1, r_return_value=..., r_call_error=...) at ./core/object/callable_method_pointer.h:104
#27 0x000055555bd8fa71 in Callable::callp (this=0x55556b475d68, p_arguments=0x7fffffffc0c0, p_argcount=1, r_return_value=..., r_call_error=...) at core/variant/callable.cpp:50
#28 0x000055555c0d529f in Object::emit_signalp (this=0x55556b320a30, p_name=..., p_args=0x7fffffffc0c0, p_argcount=1) at core/object/object.cpp:990
#29 0x00005555585e42e6 in Object::emit_signal<String> (this=0x55556b320a30, p_name=...) at ./core/object/object.h:818
#30 0x0000555558ea5126 in EditorFileDialog::_action_pressed (this=0x55556b320a30) at editor/editor_file_dialog.cpp:403
#31 0x0000555558ec85a1 in call_with_variant_args_helper<EditorFileDialog>(EditorFileDialog*, void (EditorFileDialog::*)(), Variant const**, Callable::CallError&, IndexSequence<>) (p_instance=0x55556b320a30,
    p_method=(void (EditorFileDialog::*)(EditorFileDialog * const)) 0x555558ea4d9e <EditorFileDialog::_action_pressed()>, p_args=0x0, r_error=...) at ./core/variant/binder_common.h:262
#32 0x0000555558ec6f7b in call_with_variant_args<EditorFileDialog> (p_instance=0x55556b320a30, p_method=(void (EditorFileDialog::*)(EditorFileDialog * const)) 0x555558ea4d9e <EditorFileDialog::_action_pressed()>, p_args=0x0,
    p_argcount=0, r_error=...) at ./core/variant/binder_common.h:376
#33 0x0000555558ec559c in CallableCustomMethodPointer<EditorFileDialog>::call (this=0x55556b3be810, p_arguments=0x0, p_argcount=0, r_return_value=..., r_call_error=...) at ./core/object/callable_method_pointer.h:104
#34 0x000055555bd8fa71 in Callable::callp (this=0x555572d73998, p_arguments=0x0, p_argcount=0, r_return_value=..., r_call_error=...) at core/variant/callable.cpp:50
#35 0x000055555c0d529f in Object::emit_signalp (this=0x55556b320a30, p_name=..., p_args=0x0, p_argcount=0) at core/object/object.cpp:990
#36 0x0000555557eb4b10 in Object::emit_signal<>(StringName const&) (this=0x55556b320a30, p_name=...) at ./core/object/object.h:818
#37 0x000055555a21fba6 in AcceptDialog::_ok_pressed (this=0x55556b320a30) at scene/gui/dialogs.cpp:107
#38 0x000055555a229a8a in call_with_variant_args_helper<AcceptDialog>(AcceptDialog*, void (AcceptDialog::*)(), Variant const**, Callable::CallError&, IndexSequence<>) (p_instance=0x55556b320a30,
    p_method=(void (AcceptDialog::*)(AcceptDialog * const)) 0x55555a21fb36 <AcceptDialog::_ok_pressed()>, p_args=0x0, r_error=...) at ./core/variant/binder_common.h:262

I've done more testing. All Godot 4 official alpha releases between 1 and 14 segfault on loading my project.
Also - the patch makes Godot crash consistently when I try to load any scene. I am not sure it helps any - the crashing is delayed, but it's not any more useful unfortunately.

I have this problem just resurfaced in another branch of my project:
Thread 1 "godot" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000055555b57448f in CommandQueueMT::_flush (this=0x55556154e3d0) at ./core/templates/command_queue_mt.h:373
#2  0x000055555b574524 in CommandQueueMT::flush_if_pending (this=0x55556154e3d0) at ./core/templates/command_queue_mt.h:404
#3  0x000055555b58c714 in RenderingServerDefault::global_shader_parameter_get_type (this=0x55556154e190, p1=...) at servers/rendering/rendering_server_default.h:927
#4  0x000055555b5d2b84 in ShaderCompiler::_get_variable_type (p_type=...) at servers/rendering/shader_compiler.cpp:1352
#5  0x000055555b6053f6 in ShaderLanguage::_parse_shader (this=0x555561cbf158, p_functions=..., p_render_modes=..., p_shader_types=...) at servers/rendering/shader_language.cpp:8355
#6  0x000055555b612309 in ShaderLanguage::compile (this=0x555561cbf158, p_code=..., p_info=...) at servers/rendering/shader_language.cpp:9750
#7  0x000055555b5d2c99 in ShaderCompiler::compile (this=0x555561cbf158, p_mode=RenderingServer::SHADER_SPATIAL, p_code=..., p_actions=0x7fffffffcd10, p_path=..., r_gen_code=...)
    at servers/rendering/shader_compiler.cpp:1363
#8  0x000055555b740f9b in RendererSceneRenderImplementation::SceneShaderForwardClustered::ShaderData::set_code (this=0x555579c4ce80, p_code=...)
    at servers/rendering/renderer_rd/forward_clustered/scene_shader_forward_clustered.cpp:143
#9  0x000055555b77e5b0 in RendererRD::MaterialStorage::shader_set_code (this=0x555561589b50, p_shader=..., p_code=...) at servers/rendering/renderer_rd/storage_rd/material_storage.cpp:2395
#10 0x000055555b5c4419 in CommandQueueMT::Command2<RendererMaterialStorage, void (RendererMaterialStorage::*)(RID, String const&), RID, String>::call (this=0x7fffbc1cb878)
    at ./core/templates/command_queue_mt.h:322
#11 0x000055555b57448f in CommandQueueMT::_flush (this=0x55556154e3d0) at ./core/templates/command_queue_mt.h:373
#12 0x000055555b574524 in CommandQueueMT::flush_if_pending (this=0x55556154e3d0) at ./core/templates/command_queue_mt.h:404
#13 0x000055555b58a46f in RenderingServerDefault::canvas_item_clear (this=0x55556154e190, p1=...) at servers/rendering/rendering_server_default.h:862
#14 0x000055555a0b5293 in CanvasItem::_redraw_callback (this=0x5555669d6e60) at scene/main/canvas_item.cpp:130
#15 0x0000555558ef7f6a in call_with_variant_args_helper<CanvasItem>(CanvasItem*, void (CanvasItem::*)(), Variant const**, Callable::CallError&, IndexSequence<>) (p_instance=0x5555669d6e60,
    p_method=(void (CanvasItem::*)(CanvasItem * const)) 0x55555a0b5238 <CanvasItem::_redraw_callback()>, p_args=0x0, r_error=...) at ./core/variant/binder_common.h:262
#16 0x0000555558ef5660 in call_with_variant_args<CanvasItem> (p_instance=0x5555669d6e60, p_method=(void (CanvasItem::*)(CanvasItem * const)) 0x55555a0b5238 <CanvasItem::_redraw_callback()>, p_args=0x0,
    p_argcount=0, r_error=...) at ./core/variant/binder_common.h:376
#17 0x0000555558ef1ef6 in CallableCustomMethodPointer<CanvasItem>::call (this=0x5555767e04a0, p_arguments=0x0, p_argcount=0, r_return_value=..., r_call_error=...)
    at ./core/object/callable_method_pointer.h:104
#18 0x000055555bf759c9 in Callable::callp (this=0x7fffe6324ee8, p_arguments=0x0, p_argcount=0, r_return_value=..., r_call_error=...) at core/variant/callable.cpp:50
#19 0x000055555c2bc1e2 in MessageQueue::_call_function (this=0x55556056f4b0, p_callable=..., p_args=0x7fffe6324f00, p_argcount=0, p_show_error=false) at core/object/message_queue.cpp:229
#20 0x000055555c2bc531 in MessageQueue::flush (this=0x55556056f4b0) at core/object/message_queue.cpp:275
#21 0x000055555a15a8fa in SceneTree::physics_process (this=0x555563b9ed90, p_time=0.016666666666666666) at scene/main/scene_tree.cpp:429
#22 0x0000555557b96740 in Main::iteration () at main/main.cpp:2975
#23 0x0000555557b3c9f2 in OS_LinuxBSD::run (this=0x7fffffffd840) at platform/linuxbsd/os_linuxbsd.cpp:538
#24 0x0000555557b37250 in main (argc=4, argv=0x7fffffffdd78) at platform/linuxbsd/godot_linuxbsd.cpp:72

With 100% confidence, this specific bug (based on the stack trace posted here) was fixed by #66813 so it should not happen again. As such, I will close this issue. If for some reason you encounter it again its likely a different crash so please open a new issue.

Thanks, I have not experienced this in Beta 11 so I think it is gone. Yay!


Changes to dispatch in dbt v0.20

Hi Rasmus & team! I wanted to give you a heads up about a change coming in dbt v0.20.
Required code change
We've made a change to adapter.dispatch: Instead of passing a _get_namespaces() macro to the packages arg, you should pass the name of this package (as a string) to the macro_namespace arg, which is now the second positional argument.
In practice, this just looks like switching each macro like:
https://github.com/kristeligt-dagblad/dbt_ml/blob/0a05ee31d7df05fc80466fd5ae3e415a27748c08/macros/materializations/model.sql#L1-L9
To:
{% macro drop_model(relation) %}
    {{
        adapter.dispatch(
            macro_name='drop_model',
            macro_namespace='dbt_ml'
        )
        (relation)
    }}
{% endmacro %}

For the README
If a user wishes to override/shim this package, instead of defining a var named dbt_ml_dispatch_list, they should now define a config in dbt_project.yml, for instance:
dispatch:
  - macro_namespace: dbt_ml
    search_order: ['my_project', 'dbt_ml']  # enable override

Notes
This change is in dbt v0.19.2 as well. Both v0.19.2 and v0.20.0 have backwards compatibility for the old syntax, so there's no huge rush to upgrade. The old syntax will start raising a deprecation warning in v0.20. As soon as you do upgrade to the new syntax, you'll need to require dbt >= 0.19.2 (or just >=0.20.0, for simplicity, since you're already making compatibility changes in #69).
See also:

https://github.com/fishtown-analytics/dbt/issues/3383
https://next.docs.getdbt.com/reference/dbt-jinja-functions/dispatch

Thank you, @jtcohen6. We'll get on it.


Global constant namespace

Feature you want to implement
To provide a global constant (read-only) namespace which can be accessed by any apps in a qiwis system.
For example, artiq-proxy server host ip and port information can be stored in it.
This will be initialized by the "setup.json" file.
How the feature is implemented
When loading the set-up file, the global constant namespace is initialized by the contents in the file.
However, sharing a mutable object among the apps is against our philosophy.
Therefore, the namespace must be immutable, i.e., read-only.
namedtuple seems a nice candidate for this..
Additional context
Suggested by: @BECATRUE

Oh, thanks for the details!


Update kfp component files to include optional parameter

Update the component definitions to align with best practices
when defining required inputs

What changes were proposed in this pull request?

How was this pull request tested?

Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

Could we add a comment at the beginning of each example component file:

Since Elyra re-uses existing components that were published by somebody else, we should document the raw URL where the YAML file originally came from , e.g.# Component source location: https://...

Often there is not enough information in the specification for the user to make an informed decision about valid values. If one exists, we should  reference a web page (if applicable) that contains more details. For example, https://github.com/kubeflow/pipelines/blob/master/components/kubeflow/kfserving/README.md# Component details: https://

@akchinSTC Could you please update the license and list the origin + license of these component files

@akchinSTC @kiersten-stokes Could you please resolve conflicts.


Update Golang to 1.22 in Dockerfile

Required check list:

[x ] I didn't find in the repository's issues section a similar bug.
[ x] I understand, this is an Open Source and not-for-profit product.
[ x] This is not about a third-party project, framework, or technology.

My environment:
Gowebly CLI: v2.3.1 (build with go1.22.0 on darwin/arm64)
│
│ Go: 1.22.0 darwin/arm64
│ Node.js version: 20.10.0 (npm 10.2.3)
│ Bun version: 1.0.29
│
│ Is Air tool installed? true
│ Is Templ package installed? true

...
Describe the bug:
In the main Dockerfile, we need to upgrade Golang to 1.22
...

Hi, @superjose
Thanks! Nice catch.
Fixed in v2.3.2.

@koddr
Thanks to you!
I've begun using gowebly and it's been amazing!
For instance, I didn't know Parcel had been upgraded to eslint capabilities!
Thank you thank you for the CLI!!!


Update for dnscrypt-proxy 2.1.0+ compatibility

These commits contain changes to support dnscrypt-proxy version 2.1.0 and above. The currently used version 2.0.42 is from 26th March 2020 and quite outdated.
I attempted to automatically remove the daemonize configuration setting as it caused dnscrypt-proxy to exit with an error.
Most other changes were renaming of configuration settings as per the 2.1.0 and above spec of dnscrypt-proxy.
In the future the fallback_resolvers setting will also have to be renamed to bootstrap_resolvers but as of now there is only a deprecation warning.
Some other changes such as the new NOT_READY return code might be worth implementing in the query log tab too.

Thanks for the information.
But I have 1 question: how to update SimpleDNS with the new configuration / how to make this configuration work with SimpleDNS?
Thank you in advance for your attention to my question

Thanks for the information. But I have 1 question: how to update SimpleDNS with the new configuration / how to make this configuration work with SimpleDNS? Thank you in advance for your attention to my question

I'm not quite sure I understand your question?
If you build and run<PHONE_NUMBER>6b0ca6bddc7813597f634e5fedb7c8 then your configuration should be automatically updated to the new format.
If you want to use the 0.7.1 release then changing your configuration to the new format manually probably won't work as SimpleDnsCrypt will likely overwrite your changes. I haven't verified this situation but this is what I assume would happen

Thanks for your answer.
Actually, I installed the EXE program "Simple DnsCrypt 0.7.1" by Christian Hermann (Windows 10) and now I would like to use it with the new version of dnscrypt-proxy 2.1.0.
What do I need to download / what program do I need to use to make this work? (I am definitely not a programming specialist).

If you build and run<PHONE_NUMBER>6b0ca6bddc7813597f634e5fedb7c8 then your configuration should be automatically updated to the new format>

I actually tested with "Simple DnsCrypt" a version of dnscrypt-proxy 2.1.0 that I downloaded and found that the program was no longer working properly. So I reinstalled the old version completely.
If I'm not wrong, there are some questions that might be similar to mine, especially on:
https://github.com/bitbeans/SimpleDnsCrypt/issues/557

Thanks for your answer.
Actually, I installed the EXE program "Simple DnsCrypt 0.7.1" by Christian Hermann (Windows 10) and now I would like to use it with the new version of dnscrypt-proxy 2.1.0. What do I need to download / what program do I need to use to make this work? (I am definitely not a programming specialist).

If you build and run 4057862 then your configuration should be automatically updated to the new format>

You would need Microsoft Visual Studio 2017 or newer with the C# programming toolchain to compile the program from source. As I do not have access to Christian's signing and packaging setup to create an easy installer the best I could do is distribute unsigned versions that would have to be installed via drag&drop. I could provide these if demand is high enough.

I actually tested with "Simple DnsCrypt" a version of dnscrypt-proxy 2.1.0 that I downloaded and found that the program was no longer working properly. So I reinstalled the old version completely.

As you have experienced, the old 0.7.1 version of SimpleDnsCrypt does not work with version 2.1.0 or newer of dnscrypt-proxy. Currently you would have to either use the old version of SimpleDnsCrypt with the shipped version of dnscrypt-proxy or compile the latest commit of my fork to get compatibility with dnscrypt-proxy 2.1.0+.

If I'm not wrong, there are some questions that might be similar to mine, especially on: #557

I have noticed these requests quite a long time ago. It puzzles me that no one has yet tried to solve the issue by themselves.

Thank you for your feedback.
I will try to use Microsoft Visual Studio 2017 to install the new dnscrypt.
However, I will keep an eye out for a possible update or alternative solution you come up with.
The program "Simple DnsCrypt" is a great tool! It would be sad to abandon it.

I have created an unofficial 0.7.2 version for now in case anyone stumbles upon this pull request and doesn't want to compile the code themselves. Please read the release notes carefully to prevent avoidable troubleshooting.


Drag and drop of a folder with more than 100 files uploads only 100 files.

Steps to reproduce:

Use Google Chrome
Drag and drop folder with more than 100 files within.

Only 100 files will be uploaded.
Resumable.js version: 1.1.0

I have created PR for this

Merged with thanks.

I am still seeing this issue, was it solved?


Free Moveing

I am looking to integrate feature like interact.js with dragula ,  so i can free move object in absolute containers, or Sorting this object like the current implementation  (Sorting container).
Is this functionality are planned, or any help how i can do it ?

Anyone?


Test workflow permission of PRs from internal members.

Finished testing the whitelist membership check. Close the PR.


[VQC-CHALLENGE] [Quantum Annihilating] [2022-11-3]

Team members
Nouhaila Innan
Jehanne Reinkaos
Hasan Mustafa
Prashik Somkuwar
Submission summary
100% Accuracy
Additional comments

Thanks for your submission! Your model achieved 100% accuracy with a quantum cost of 197.52, and currently ranks 10th on the overall leaderboard.
REMINDER: The final submission deadline is Friday, November 4th 10am EST, and any new PR's opened will not be reviewed until after the deadline.


Make copy when deleting instead of messing up range operations

We would walk the labels and comments lists and could then delete from
them. Since we used the form a = append(a[:i], a[i+1:...]) we were
actually changing the list as it was being used in a range a
statement. This could cause the comment deleter and the LGTM label
checker to go nuts.

LGTM

Thank you @knobunc @jayunit100


listener: merge slashes in path

Some deployments want to have the slashes merged in the paths https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto.html?highlight=merge_slashes. This can not be achieved by EnvoyFilter because it is a simple boolean and proto.merge will fail.
This PR controls that behaviour via config option defaulted to false.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[X ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ ] Does not have any changes that may affect Istio users.

@ramaraochavali: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
7546f1d15f1a46bcf0e09de6fad96cba1e475610
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@dgn No. It is not possible to do it via Envoy Filters because of this bug https://github.com/istio/istio/issues/18169

@dgn No. It is not possible to do it via Envoy Filters because of this bug #18169

that only affects values that are set to true by default and you want to set them to false using an EnvoyFilter. In this case it's the other way around and should work

BTW, this is not a backdoor entry for features - these has been a precedent for such things like USE_REMOTE_ADDRESS https://github.com/istio/istio/blob/master/pilot/pkg/features/pilot.go#L143

@dgn  Thanks. Looks like it works merge_slashes works.  Not sure why it did not when I tried earlier.  Sorry for the confusion. Closing  this PR


[CARBONDATA-3492]: Added prepriming in the Index Server Documentation

Why is this PR needed?
This PR consists of the documentation changes for the feature Index Server Cache Prepriming.
What changes were proposed in this PR?
Index Server Documentation changes are made in this.
Does this PR introduce any user interface change?

No

Is any new testcase added?

No

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1525/

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1580/

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/1581/


CVE-2015-5723: Security vulnerability with file/directory creation

Reported as CVE-2015-5723. For additional context, please see: http://www.doctrine-project.org/2015/08/31/security_misconfiguration_vulnerability_in_various_doctrine_projects.html

@malarzm fixed this in:

https://github.com/doctrine/mongodb-odm/commit/d23d95c04a52dc8d682c8d023c136c67c8330277
https://github.com/doctrine/mongodb-odm/commit/3f135950bbf31e72f544238acd9f0ce2084a1073


Option to polyfill window.customElements separately

Some work needs to be done to allow the custom elements polyfill to be splittable from the shadow dom polyfill, such that they can still be interwoven in the browsers that need both, but authors can also dynamically include smaller, more precise scripts as needed.
A second look should also be taken at getting the Shadow DOM polyfill to work alongside https://github.com/WebReflection/document-register-element.

Closing this; correct behavior of Custom Elements depends on the DOM algorithms.


Training on train/val split issue.

Hi I noticed in the default config/config.yaml the trainval_split is set to false, and there is no such train_val_split.pkl file in extra data:
 ## here is what I found  in file config/config.yaml
  trainval_split: false
  split_file: "train_val_split.pkl"

Does it suggest that the following example training script uses full training images instead of a train/val split of views (as described in the paper)?
(EXP=car/structured ID=157_17286_33548; python exp_runner.py gpu=0 mode=train config.file=exp/$EXP/config.yaml config.exp_name=$EXP/${ID} dataset.instance=\'$ID\')
If it does, how should I reproduce the results in the paper? To be more specific, after setting trainval_split: true, I found two potential split files (namely train_val_split_official.pkl and train_val_structured_split.pkl), which should I use?

Hi, I apologise for the late reply. Both splits are used to reproduce the results in the paper. The official and the structured splits are both used in the paper and are described in sections 5.2 and 5.3 respectively. Structured split is created specifically for our paper and excludes a portion of the object on its one side in order to test the ability of the model to perform symmetric reconstruction. I hope that helps!


Render: fail if no oauth image is found

For some unknown reason, during upgrades from ACM 2.11, the template image is briefly used, instead of the image from the openshift imagestream. The template image is not available in disconnected environments, and as a result causes the pods be unable to come up.
This is a problem especially for alertmanager. Because of it being a statefulset when it gets into the bad state, with the wrong image, it doesn't automatically recover on the next reconcile. This requires manual intervention to fix.
Instead with this PR, we make the reconcile fail if we do not find the oauth image. This will make it retry later, when the imagestream is able to be found.

/test test-e2e

/test test-e2e

Note this causes reconciles to fail (intentionally) if we cannot find the imagestream. Not sure if there is a more graceful method? It will basically keep all images on the older versions during an upgrade, until the we can get the correct image. It seems we will keep trying to reconcile until it works, so probably works OK.
Error:
2024-11-15T16:06:02.194Z ERROR controller_multiclustermonitoring Failed to render multiClusterMonitoring templates {"Request.Namespace": "open-cluster-management", "Request.Name": "mch-updated-request", "error": "failed to get OAuth image for Grafana"}
github.com/stolostron/multicluster-observability-operator/operators/multiclusterobservability/controllers/multiclusterobservability.(*MultiClusterObservabilityReconciler).Reconcile
/workspace/operators/multiclusterobservability/controllers/multiclusterobservability/multiclusterobservability_controller.go:280
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.1-0.20240626171621-700befecdffa/pkg/internal/controller/controller.go:114
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.1-0.20240626171621-700befecdffa/pkg/internal/controller/controller.go:311
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.1-0.20240626171621-700befecdffa/pkg/internal/controller/controller.go:261
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.1-0.20240626171621-700befecdffa/pkg/internal/controller/controller.go:222
2024-11-15T16:06:02.194Z ERROR Reconciler error {"controller": "multiclusterobservability", "controllerGroup": "observability.open-cluster-management.io", "controllerKind": "MultiClusterObservability", "MultiClusterObservability": {"name":"mch-updated-request","namespace":"open-cluster-management"}, "namespace": "open-cluster-management", "name": "mch-updated-request", "reconcileID": "8fc754de-955e-4748-8faa-233d48b97297", "error": "failed to get OAuth image for Grafana"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.1-0.20240626171621-700befecdffa/pkg/internal/controller/controller.go:324
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.1-0.20240626171621-700befecdffa/pkg/internal/controller/controller.go:261
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.1-0.20240626171621-700befecdffa/pkg/internal/controller/controller.go:222

/test test-e2e

/override "SonarCloud Code Analysis"

/override "ci/prow/sonarcloud"

/cherrypick main


ID-396 Content changes for donor confirm identity screen

Purpose
Changes to the how will you confirm identity page for donor. To implement Figma: https://www.figma.com/design/pEYIyMBoWCGAvTclJFMOsq/Paper-ID-ideas?node-id=7979-43641&node-type=frame&t=GBRaEfV1izMR9N49-0
Approach
Markup changes

theres also a failing cypress test - i'm not too familiar with cypress myself yet but looks like some changes are needed in donor-journey.cy.ts to match your changes.

@davidbridgwood All passing now


Featured programs

Resolves #99
Brief description
Created pages for programs and a data store using Zustand. Changed the home page featured program section to pull data from the data store if the flag element is set to true.
Checklist

[x] I have built this pull request locally
[ ] I have ran the unit tests locally
[x] I have manually tested this pull request
[x] I have reviewed my pull request
[ ] I have added any relevant tests

Demonstration

Lgtm


Propagate click event under the accuracy circle

@domoritz  I could not propagate click event to the layer under the accuracy circle. Is there a way to do it?

Just solved it by putting property interactive: false in circleStyle property of locate control!!


Zoom question

There is an example on c3 which uses "mouse wheel" to zoom in. My question is: can I use drag selection to rubber-band a rectangle and use that to zoom in?
I see this behaviour in a sub-chart - but we do not have sub charts and would like to zoom in the main chart using selection rather than middle mouse wheel.
If this functionality does not exist, will it be easy to look at source and add this ability - I know some d3.js and am not entirely familiar with c3 internals.

Hi @psinghsp! This would be a really good question to ask the Google Group. There might be a way to do it already, just I'm not familiar with it. Mind asking there? Thanks!