Crashing, but why? I don't understand the error message

Help
1

Godot Version

v4.2.stable.official [46dc27791]

Question

When I run my game (written using gdscript), after a short, random amount of time (e.g. within minutes) it is crashing. There is nothing in the output window except “Debugging process stopped”. In the godot.log file it states the following:

USER ERROR: FATAL: Index p_index = 4294967295 is out of bounds (count = 122).
   at: operator[] (./core/templates/local_vector.h:161)

That line of code (as per a quick look in github) seems to me to just be where the error is reported rather than what it is being reported about. Beyond it being an indexing error, what does it mean? How did it get to that line? What is a “local_vector” related to?

Is the big number actually a small negative number? If it is, I still don’t know what it relates to.

Any help appreciated.

1 Like
2

I think something is overflowing or you try to access something that doesn’t have value.
Most likely something at line 161

3

Yes, but the error is at line 161 in the Godot engine, not in my gdscript code.

1 Like
4

I’m currently thinking it’s to do with 3D collision shapes and SpringArm3D.

Seems to occur when character is in tight spots, and it probably doesn’t help that I’m changing which collision shapes are active based on the stance the character is in (e.g. standing, crouched etc) which I’m partly controlling based on how much headroom there is via a SpringArm3D. I also have one in the opposite direction to find the distance down to the floor.

It’s a third person character so I’m also using a SpringArm3D for the camera mount and I’m changing the spring arms position.y based on the stance (e.g. it’s lower when crouched).

Note that it doesn’t seem to occur directly I change which collision shapes are enabled. Is the use of “local_vector” by the engine anything to do with either collision shapes or spring arms?

Am I going about this in the wrong way? What I’m currently doing seems to have the affect I want to achieve - if only it wasn’t mysteriously crashing.

EDIT:
I thought I’d fixed the issue by moving the SpringArm3D I was using to detect the headroom to above the ground level (to 0.2m). There were a few areas where it had been consistently crashing within a few seconds and moving it up does seem to have stopped this from happening. However I went past a wall like structure (some upright-ish poles) and it crashed again, so not a 100% solution, but I think I’m now in the right area as to what is going wrong. I’m presuming it’s crashing when the SpringArm is “in the floor”, or rather inside a collision shape. (note also that the spring arm has a CylinderShape3D on top of it instead of just casting a ray).

Additionally, removing the collision shapes from the ends of the spring arms seems to stop it crashing, however it stops other things working as the single rays miss objects that I need them to intersect with.

5

Made some more tweaks and it seems to be working now…
I’ve:

  • changed the collision shape at the end of the arms from cylinders to spheres which is more in line with the capsule shapes of the body’s colliders.
  • increased the radius of these collision shapes to 0.25m which is more in line with the shape of the body (I may need to simplify the body shape as it’s currently made of 4 colliders of radii from 0.15m to 0.25m, which are turned on and off based on the stance - I might end up needing all the sizes to match).
  • moved both distance SpringArm3D’s to 0.3m above the ground.
  • changed the code for returning the headroom to deduct 0.55m
  • changed the code for returning the distance to the floor to deduct 0.05m

I think these changes will (mostly) stop the spring arms ending up in the middle of geometry. I might get issues if the physics frame delta goes above what it should be. Having a large distance that isn’t checked / possible to have objects in is also not ideal.

I’ll need to find a separate solution for crawling as the distances are smaller, but I’ve yet to try implementing that yet.

If this is the reason / solution, it could probably do with a better error message, preferably one in the debug output, perhaps along the lines of “problem with calculating SpringArm3D position”.

6

It sounds like a Godot bug. If you’re interested in getting it fixed, I suggest trying to make it happen more instead of less. If you can isolate it to the simplest possible project that causes the error, you can open an issue ticket to try to get it fixed. You can also search the current open issues for anything that looks related.

7

local_vector.h:161 • only info :godot:

image
image1226×180 26.1 KB

1 Like
8

I have tried creating a new (simpler) project to demonstrate the issue, but have been unable to get it to crash. I’ll try some more to recreate it. I have searched around, originally for local_vector and again now for spring arm, but have been unable to find anything.
It’s either a bug because it shouldn’t crash, or it’s an unhelpful error message - it is reported as being a fatal user error, so someone decided that if it happened then it’s because of something I (as the user) have done, but failed to report what (I’m guessing local_vector is some sort of C++ prototype/parent class to some concrete class, perhaps Vector2, Vector3 etc although it would make more sense if it was related to some sort of array structure, maybe those in CollisionPolygon3D shapes etc). As I’ve so far been unsuccessful in recreating it, I can’t really say which it is. I also can’t definitively say it’s because of SpringArm3D.

9

If you manage to reproduce the bug in your original project, you can save a few copies of that project (or better yet use version control such as Git) and then experiment with removing extraneous things while still being able to reproduce the error. Save multiple versions as the project gets smaller and simpler, until you can narrow down the source of the problem. This will inform you of where the danger is, and also enable Godot contributors to figure out how to fix the bug in Godot.

10

I’d considered that, but I’ve currently added 1040 files to the project… (it’s not tiny).
Plus Godot has a tendency to crash if you remove the wrong things (e.g. due to dependencies).

At some point I might start the other way and take aspects of the project and build it up until it crashes, however that doesn’t give a good small demonstration of the problem, but at least if I had a clear understanding of the problem it would be easier to recreate the problem.

If I get desperate I might even take a look at the C++ to try to figure out myself what uses that bit of code where the error is reported, but my background is 4GLs, databases, Unix scripting, Java etc rather than C++.

11

Progress (or rather lack of it) report.

Crashed again - after testing it following making some changes to the characters AnimationTree. Removing the changes seemed to stop the crashes (although the crashing isn’t 100% consistent to reproduce, so it might have just made it occur less often).
Therefore looked into what uses local_vector - there are about 100 C++ sources that use it, it seems to be some sort of array rather than being related to Vector2, Vector3 etc as I’d previously presumed - it isn’t mentioned in SpringArm3D either. The contents of these local_vectors is open ended, hence the use of T. The lack of reference to it in SpringArm3D potentially could explain why I was having problems recreating it in another project, although other code that SpringArm3D utilises may use it. So realistically I’m back to having no idea.

I suppose, given a change to the AnimationTree led to another crash, my problem might relate to that. I tried adding similar animation stuff to my recreation project, and it still fails to fail (e.g. it doesn’t crash).

Note also that I also sometimes see the error “This function in this node … AnimationTreeEditor … can only be accessed from either the main thread or a thread group”. It happens mostly when loading the project, but doesn’t always occur, and the number of times the message is repeated varies. But as it relates to the editor and notes regarding the error relate to the editor it probably isn’t related.

Question:
Is there no way of creating a stack trace when it crashes? I tried using --verbose and --debug, but neither improve on the error report.

PS a new routine has been added to local_vector.h in git, so the line numbers have now changed. The code that was on line 161 is now on line 177. The new routine is irrelevant as it is for new functionality.

1 Like
12

The number quoted is significant. It’s 2^32 -1, which is the maximum value for an unsigned integer with 2 bytes. Definitely an overflow.

13

Thanks. I probably shouldn’t have put “a small negative number”, I should have put -1, I did know it was how -1 was typically represented as a signed 32 bit, it makes some maths easier as -2 add 1 is -1 so you don’t need to do anything different for negative numbers to using positive numbers, plus traversing 0 is just a case of rolling the top bit off etc. However in my experience most languages that report signed numbers would report them as negative numbers rather than as positive numbers, so as I don’t know Godot or C++ very well I didn’t want to make an assumption about it.
PS I’ve also seen languages store -1 as 2147483649, I think it might be to simplify multiplication, but I’m not sure - it could just be the writers were a bit bonkers.

PPS edit: I actually miss-read what you put - a bad assumption on my part that I made when trying to avoid making assumptions. It’s probably more likely to be an underflow rather than an overflow as as well as being the highest unsigned 32bit integer it’s (normally given my previous caveat) also the same bit pattern as the smallest signed 32bit integer, e.g. -1 (PPPS I think you meant 4 bytes).
I’m getting a little “pulling my hair out” not being able to figure out what is going wrong. If the Godot engine reported some sort of stack trace when it crashes I’d have some idea where to look for the issue, but it might be that for performance reasons it doesn’t store such information and therefore can’t report it, it only reports the line of C++ code it crashed on, which in this case is unhelpful as it’s not related to it’s usage.

14

Another progress update.

Downloaded VSC, python and scons as per “Compiling for windows”.
Generated version of godot from the latest git files that I’d downloaded.
Ran it up with a copy of my project, converted it to 4.3 and tried to get it to crash.
My plan was to try to put some sort of reporting into the sources to try and see what was going wrong. Looks like somebody got there first. Message now reads:

USER ERROR: FATAL: Index p_index = 4294967295 is out of bounds (count = 114).
   at: LocalVector<struct BVH_Tree<class GodotCollisionObject3D,2,2,128,class GodotBroadPhase3DBVH::UserPairTestFunction<class GodotCollisionObject3D>,class GodotBroadPhase3DBVH::UserCullTestFunction<class GodotCollisionObject3D>,1,struct AABB,struct Vector3>::TNode,unsigned int,1,0>::operator [] (.\core/templates/local_vector.h:177)

================================================================
CrashHandlerException: Program crashed
Engine version: Godot Engine v4.3.dev.custom_build
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[0] <couldn't map PC to fn name>
[1] <couldn't map PC to fn name>
... etc. to...
[26] <couldn't map PC to fn name>
[27] <couldn't map PC to fn name>
-- END OF BACKTRACE --
================================================================

more to investigate, but at least it looks like the error messages are getting more informative, so somewhere to work from.

15

I think I came across the same issue - created a PR which fixes it for me Check if GodotConvexPolygonShape3D initialization happened by demolke · Pull Request #92308 · godotengine/godot · GitHub

16

Thanks for linking me in on this, it looks like it’s in a similar area to where I’m seeing issues, however I’m not changing resolution and it can happen a while after startup. It does appear to be to do with checking arrays that don’t have content so such checks may stop it crashing, although presumably it will also lead to side effects of “falling through the cracks” as there will be missing colliders.

17

I tried your suggested changes to godot_shape_3d and I still have the same problem. However I think it’s probably an area I should have another look into - but at the moment I have little understanding of what any of the c++ code does, when it does it or how it fits together.
It could be along the lines that I’ve just defined a CollisionPolygon3D’s array incorrectly somewhere or the way I’ve stacked multiple collision shapes under StaticBody3D’s or my toggling of objects visibility, or… Yes, at the moment it could still be just about anything.

18

Interesting - if you’re compiling your own version, build the dev_build version to get a proper stack trace, that should help pinpoint the issue.

19

Cheers. I only read the compiling for windows page. I tried compiling it with the thought of trying to add some debug code to it, but didn’t get very far. Originally when starting out with Godot it wasn’t my intention to work on c++ code :slightly_smiling_face:
I’ll give that a try.

20

That made the trace more interesting than 28 couldn’t map PC to fn name’s…

USER ERROR: FATAL: Index p_index = 4294967295 is out of bounds (count = 184).
   at: LocalVector<struct BVH_Tree<class GodotCollisionObject3D,2,2,128,class GodotBroadPhase3DBVH::UserPairTestFunction<class GodotCollisionObject3D>,class GodotBroadPhase3DBVH::UserCullTestFunction<class GodotCollisionObject3D>,1,struct AABB,struct Vector3>::TNode,unsigned int,1,0>::operator [] (E:\godotBuild\godot-master\core/templates/local_vector.h:177)

================================================================
CrashHandlerException: Program crashed
Engine version: Godot Engine v4.3.beta.custom_build
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[0] LocalVector<BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::TNode,unsigned int,1,0>::operator[] (E:\godotBuild\godot-master\core\templates\local_vector.h:177)
[1] PooledList<BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::TNode,unsigned int,1,0>::operator[] (E:\godotBuild\godot-master\core\templates\pooled_list.h:90)
[2] BVH_Tree<GodotCollisionObject3D,2,2,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,1,AABB,Vector3>::item_move (E:\godotBuild\godot-master\core\math\bvh_public.inc:123)
[3] BVH_Manager<GodotCollisionObject3D,2,1,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,AABB,Vector3,1>::move (E:\godotBuild\godot-master\core\math\bvh.h:201)
[4] BVH_Manager<GodotCollisionObject3D,2,1,128,GodotBroadPhase3DBVH::UserPairTestFunction<GodotCollisionObject3D>,GodotBroadPhase3DBVH::UserCullTestFunction<GodotCollisionObject3D>,AABB,Vector3,1>::move (E:\godotBuild\godot-master\core\math\bvh.h:141)
[5] GodotBroadPhase3DBVH::move (E:\godotBuild\godot-master\servers\physics_3d\godot_broad_phase_3d_bvh.cpp:45)
[6] GodotCollisionObject3D::_update_shapes (E:\godotBuild\godot-master\servers\physics_3d\godot_collision_object_3d.cpp:182)
[7] GodotCollisionObject3D::_shape_changed (E:\godotBuild\godot-master\servers\physics_3d\godot_collision_object_3d.cpp:236)
[8] GodotPhysicsServer3D::_update_shapes (E:\godotBuild\godot-master\servers\physics_3d\godot_physics_server_3d.cpp:1736)
[9] GodotPhysicsServer3D::body_test_motion (E:\godotBuild\godot-master\servers\physics_3d\godot_physics_server_3d.cpp:920)
[10] PhysicsServer3DWrapMT::body_test_motion (E:\godotBuild\godot-master\servers\physics_server_3d_wrap_mt.h:261)
[11] PhysicsBody3D::move_and_collide (E:\godotBuild\godot-master\scene\3d\physics\physics_body_3d.cpp:109)
[12] CharacterBody3D::_move_and_slide_grounded (E:\godotBuild\godot-master\scene\3d\physics\character_body_3d.cpp:159)
[13] CharacterBody3D::move_and_slide (E:\godotBuild\godot-master\scene\3d\physics\character_body_3d.cpp:108)
[14] call_with_validated_variant_args_ret_helper<CharacterBody3D,bool> (E:\godotBuild\godot-master\core\variant\binder_common.h:375)
[15] call_with_validated_object_instance_args_ret<CharacterBody3D,bool> (E:\godotBuild\godot-master\core\variant\binder_common.h:663)
[16] MethodBindTR<CharacterBody3D,bool>::validated_call (E:\godotBuild\godot-master\core\object\method_bind.h:538)
[17] GDScriptFunction::call (E:\godotBuild\godot-master\modules\gdscript\gdscript_vm.cpp:2094)
[18] GDScriptInstance::callp (E:\godotBuild\godot-master\modules\gdscript\gdscript.cpp:2050)
[19] Node::_gdvirtual__physics_process_call<0> (E:\godotBuild\godot-master\scene\main\node.h:352)
[20] Node::_notification (E:\godotBuild\godot-master\scene\main\node.cpp:60)
[21] Node::_notificationv (E:\godotBuild\godot-master\scene\main\node.h:50)
[22] Node3D::_notificationv (E:\godotBuild\godot-master\scene\3d\node_3d.h:52)
[23] CollisionObject3D::_notificationv (E:\godotBuild\godot-master\scene\3d\physics\collision_object_3d.h:38)
[24] PhysicsBody3D::_notificationv (E:\godotBuild\godot-master\scene\3d\physics\physics_body_3d.h:41)
[25] CharacterBody3D::_notificationv (E:\godotBuild\godot-master\scene\3d\physics\character_body_3d.h:38)
[26] Object::notification (E:\godotBuild\godot-master\core\object\object.cpp:906)
[27] SceneTree::_process_group (E:\godotBuild\godot-master\scene\main\scene_tree.cpp:957)
[28] SceneTree::_process (E:\godotBuild\godot-master\scene\main\scene_tree.cpp:1042)
[29] SceneTree::physics_process (E:\godotBuild\godot-master\scene\main\scene_tree.cpp:491)
[30] Main::iteration (E:\godotBuild\godot-master\main\main.cpp:4014)
[31] OS_Windows::run (E:\godotBuild\godot-master\platform\windows\os_windows.cpp:1686)
[32] widechar_main (E:\godotBuild\godot-master\platform\windows\godot_windows.cpp:181)
[33] _main (E:\godotBuild\godot-master\platform\windows\godot_windows.cpp:206)
[34] main (E:\godotBuild\godot-master\platform\windows\godot_windows.cpp:220)
[35] WinMain (E:\godotBuild\godot-master\platform\windows\godot_windows.cpp:234)
[36] __scrt_common_main_seh (D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
[37] <couldn't map PC to fn name>
-- END OF BACKTRACE --
================================================================

Do you know if the line numbers get a bit… sketchy?
For instance in godot_physics_server3d.cpp line 1735 contains “_shape_changed()” where as the trace states 1736.

To me, my problem appears to do with changes to collision shapes and then having an indexing issue. Therefore I’m now presuming it’s to do with me enabling and disabling collision shapes on my character so that they can crouch/crawl etc, rather than what I was thinking before about it being to do with the mechanism by which I was determining if they should crouch/crawl etc.
(I did it by enabling and disabling collision shapes as I’d read somewhere that you shouldn’t try to change the collision shapes size, I don’t know how valid that statement was.)
Potentially I could be causing some sort of cross thread timing issue?
I’ve had a quick test with using set_deferred to enable/disable the collision shapes and although it causes some other issues (e.g. it’s now doing it a frame late and my code is probably messing up due to that as it’s testing things at the wrong time/when they are now in the wrong state), but so far it hasn’t crashed - but as I said, it was a quick test…

EDIT: tried fixing the testing of the state of the variables, using set_deferred really messed things up - it’s like gravity is all wrong at times now… One step forward…