Program crashed with signal 11

[Anyeos]

Adding a VoxelTerrain with VoxcelGeneratorNoise Sdf with an OpenSimplexNoise with default configurations, next pasing some seconds crash the entire program (except of course the Godot Editor).

I will do furter investigation but for now I only have time to post this issue and include some log:

Running: godot.x11.tools.64 --path VoxelTest --remote-debug 127.0.0.1:6007 --allow_focus_steal_pid 13675 --position 448,240 Godot Engine v3.2.1.rc1.custom_build - https://godotengine.org OpenGL ES 3.0 Renderer: Radeon RX 580 Series (POLARIS10, DRM 3.33.0, 5.3.0-40-generic, LLVM 9.0.0)

VoxelLibrary not set yet VoxelLibrary not set yet VoxelLibrary not set yet VoxelLibrary not set yet VoxelLibrary not set yet VoxelLibrary not set yet VoxelLibrary not set yet Constructing VoxelDataLoader View distance changed from 8 blocks to 64 Took 1203 us to bake VoxelLibrary Constructing VoxelMeshUpdater ERROR: resize: All memory pool allocations are in use. At: ./core/pool_vector.h:529. ERROR: resize: All memory pool allocations are in use. At: ./core/pool_vector.h:529. ERROR: resize: All memory pool allocations are in use. At: ./core/pool_vector.h:529. handle_crash: Program crashed with signal 11 Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues handle_crash: Program crashed with signal 11 Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues [1] /lib/x86_64-linux-gnu/libc.so.6(+0x46470) [0x7f53abc96470] (??:0) [1] /lib/x86_64-linux-gnu/libc.so.6(+0x46470) [0x7f53abc96470] (??:0) [2] /lib/x86_64-linux-gnu/libc.so.6(+0x16967d) [0x7f53abdb967d] (??:0) [3] void raw_copy_to(PoolVector&, std::vector<Vector3, std::allocator > const&) (src/godot-3.2/modules/voxel/meshers/blocky/../../math/../util/utility.h:95) [2] VisualServer::_surface_set_data(Array, unsigned int, unsigned int, unsigned int, PoolVector&, int, PoolVector&, int, AABB&, Vector&) (src/godot-3.2/servers/visual_server.cpp:445) [4] VoxelMesherTransvoxel::fill_surface_arrays(Array&) (src/godot-3.2/modules/voxel/meshers/transvoxel/voxel_mesher_transvoxel.cpp:152) [5] VoxelMesherTransvoxel::build(VoxelMesher::Output&, VoxelMesher::Input const&) (src/godot-3.2/modules/voxel/meshers/transvoxel/voxel_mesher_transvoxel.cpp:201) [3] VisualServer::mesh_add_surface_from_arrays(RID, VisualServer::PrimitiveType, Array const&, Array const&, unsigned int) (src/godot-3.2/servers/visual_server.cpp:1146 (discriminator 1)) [6] VoxelMeshUpdater::process_blocks_thread_func(ArraySlice<VoxelBlockThreadManager<VoxelMeshUpdater::InputBlockData, VoxelMeshUpdater::OutputBlockData>::InputBlock>, ArraySlice<VoxelBlockThreadManager<VoxelMeshUpdater::InputBlockData, VoxelMeshUpdater::OutputBlockData>::OutputBlock>, Ref, Ref) (src/godot-3.2/modules/voxel/terrain/voxel_mesh_updater.cpp:70 (discriminator 2)) [4] ArrayMesh::add_surface_from_arrays(Mesh::PrimitiveType, Array const&, Array const&, unsigned int) (src/godot-3.2/scene/resources/mesh.cpp:844) [7] src/godot-3.2/bin/godot.x11.tools.64() [0x18f6bac] (src/godot-3.2/modules/voxel/terrain/voxel_mesh_updater.cpp:48 (discriminator 2)) [5] VoxelTerrain::_process() (src/godot-3.2/modules/voxel/terrain/voxel_terrain.cpp:1051 (discriminator 3)) [8] src/godot-3.2/bin/godot.x11.tools.64() [0x18f7768] (/usr/include/c++/9/bits/std_function.h:302) [6] VoxelTerrain::_notification(int) (src/godot-3.2/modules/voxel/terrain/voxel_terrain.cpp:641) [9] std::function<void (ArraySlice<VoxelBlockThreadManager<VoxelMeshUpdater::InputBlockData, VoxelMeshUpdater::OutputBlockData>::InputBlock>, ArraySlice<VoxelBlockThreadManager<VoxelMeshUpdater::InputBlockData, VoxelMeshUpdater::OutputBlockData>::OutputBlock>, VoxelBlockThreadManager<VoxelMeshUpdater::InputBlockData, VoxelMeshUpdater::OutputBlockData>::ProcessorStats&)>::operator()(ArraySlice<VoxelBlockThreadManager<VoxelMeshUpdater::InputBlockData, VoxelMeshUpdater::OutputBlockData>::InputBlock>, ArraySlice<VoxelBlockThreadManager<VoxelMeshUpdater::InputBlockData, VoxelMeshUpdater::OutputBlockData>::OutputBlock>, VoxelBlockThreadManager<VoxelMeshUpdater::InputBlockData, VoxelMeshUpdater::OutputBlockData>::ProcessorStats&) const (/usr/include/c++/9/bits/std_function.h:690) [7] VoxelTerrain::_notificationv(int, bool) (src/godot-3.2/modules/voxel/terrain/voxel_terrain.h:21 (discriminator 14)) [10] VoxelBlockThreadManager<VoxelMeshUpdater::InputBlockData, VoxelMeshUpdater::OutputBlockData>::thread_func(VoxelBlockThreadManager<VoxelMeshUpdater::InputBlockData, VoxelMeshUpdater::OutputBlockData>::JobData&) (src/godot-3.2/modules/voxel/terrain/block_thread_manager.h:430) [8] Object::notification(int, bool) (src/godot-3.2/core/object.cpp:933) [11] VoxelBlockThreadManager<VoxelMeshUpdater::InputBlockData, VoxelMeshUpdater::OutputBlockData>::_thread_func(void) (src/godot-3.2/modules/voxel/terrain/block_thread_manager.h:372) [12] ThreadPosix::thread_callback(void*) (src/godot-3.2/drivers/unix/thread_posix.cpp:76) [9] SceneTree::_notify_group_pause(StringName const&, int) (src/godot-3.2/scene/main/scene_tree.cpp:985) [13] /lib/x86_64-linux-gnu/libpthread.so.0(+0x9669) [0x7f53ac1b9669] (??:0) [14] /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f53abd72323] (??:0) -- END OF BACKTRACE --

[TokisanGames]

Try decreasing your view distance. What is it set to and how much RAM do you have? Are you using the 64-bit version and a 64-bit kernel?

[Zylann]

Sounds like a duplicate of https://github.com/Zylann/godot_voxel/issues/97

[Anyeos]

Thank you for the support and maybe you are right it can be a memory problem but not with my computer but the project settings itself. I have 16 GB of RAM and 4 GB of VRAM there are no slowdown at all only a crash. All my system is a 64 bit and as you can look I am using a 3.2.1-custom build of Godot just pulled yesterday.

Ubuntu 19.10 64 bits with default kernel.

But I want a very far view distance because I am interested on developing a procedural FPS game with large terrains and view distance. I will use FOG to hide that but I need a far credible view distance.

I just look that on the final example that uses a shader to achieve a better terrain simulation. I am just expecting something like that too as a final result. So I think it is achievable.

[Anyeos]

Well I don't find such an option to limit memory for my project except some about the mesh buffers and video. I don't think a voxel can fill the video memory so easy. Specially when I check it is using only 30% of VRAM and the pipeline is used at 3% only. There are a lot of margin power to handle that.

All that is using is a lot of threads and full 8 cores CPU but there are still a lot of System Memory because it is using 2GB.

I will investigate what is happening with the pool. Maybe it is a problem with threads that are trying to use the same memory space than another thread.

[Anyeos]

Sounds like a duplicate of #97

Yes, it appears to be related. There are some problem with the actual code that is reproducible so fast on my computer. I have 8 cores maybe if there are more cores it is more suceptible to crash. It is a must to solve that code because actually is of no use.

[Anyeos]

I discovered that Godot have hardcoded the memory pool allocation as (1 << 16) that is 65536. I changed it to (1 << 18) and now it is working as expected.

Of course I need to change it to the export templates too. I cannot export the game for now but I will try to solve that in a future.

[TokisanGames]

Cool, what file is that in? I've noticed my Godot executable crashing with this error when it only has allocated ~3GB, even though I have plenty more.

[Anyeos]

On the file core/pool_vector.h there are the declaration: static void setup(uint32_t p_max_allocs = (1 << 16));

Or if you want you can modify it on core/register_core_types.cpp: MemoryPool::setup();

You can specify the ammount there just by someting like: MemoryPool::setup(1 << 20);

[Zylann]

This is quite curious because the biggest memory buffers allocated by this plugin (i.e voxels) are not using Godot's containers. However I suppose this is caused by mesh data because these are a Godot thing (I didn't know they stayed in memory, if there is an option to turn that off it would be cool). PoolVectors were removed in Godot's master branch, so that sort of error should no longer occur in the future.

[Zylann]

Going to close this because PoolVector limitation is no longer present in Godot 4, and in Godot 3 it needs tweaking and shouldnt actually crash. Though if it still crashes in Godot 3 that can be fixed if it happens within the module.