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.
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.
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”.
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.
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.
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.
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++.
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.
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.
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.
