When shooting entities, they move too fast, which under certain conditions makes them load too many chunks which freezes the server which then crashes due to watchdog or throws an OOM in case watchdog is disabled.
If an entity has a positive fall_distance, within its .move() call, itll cast a ray searching for fall_damage resetting blocks. If the velocity of the entity is big enough, the ray goes outside render distance, which makes it generate/load chunks. If the velocity is bug enough, the ray will load so many chunks, that the server just cant load them all in 60 seconds, which will cause the watchdog to shutdown the server. (Even when i disable the watchdog, the server still crashes with OOM, cus it cant keep all of the new chunks in the memory)
Example 25w16a: video is attached below.
Relevnt code: “falldamage_raycast.png“ attached below.
Clarification: from ingame testing, if the entity has 0 fall_distance, then it does in fact not crash the server
Please note this is a very cannon tech sensitive issue, it is very annoying when designing cannons.
We suggest fixing it by limiting the length of this raycast.
If you decide to move fall_damage resetting blocks detection into the .ApplyEffectsFromBlocks() method, you have to know that this function doesnt work properly in its current implementation as of 25w16a (because of:
Also depending on implementation, it can change the moment at which the entity gets damaged, which might break some subtick order related redstone contraptions (i cant come up with an example of such contraption, but it doesnt mean it doesnt exist).
This issue is also related to the MC-275437, which happens for almost identical reason.
Attachments
Comments 7
Savvvage_
Isn’t this related to MC-260743?
@Joel Danter no, as explained in this report, the crash happens due to chunks loading, not due to the issue described in the report you linked (the collision face collection being O(n^3)), even tho the issue you linked, can in some cases cause the server to crash too, its not nearly as severe as whats described above.
Well, you can call it “related“, technically both issues just happen to occur in roughly the same conditions, but for completely different reasons.
So, the source of the issue (falldamage raycast) seems to have been fixed in 25w32a.
However, the crash itself is still present because of the following:
raycast in MC-295841
(which, as of now, is actually not fixed, as per last comment)path search in the pathfinding of fast moving living entities also causes crashes.
Hower as stated above, thats not not the focus of this ticket, so it can be closed now.
oops, accidentlly sent the previous comment before formatting it propperly, only first and second items of the list are supposed to be there, but the point still stands, specifically the one issues described int this report should be technically fixed (even tho i cant verify it cus it is masked by other crashes simmilar)