Previous issue - #153

Confirmed in Visual VM that it's still getting stuck in the getEstimatedHealthIncrement(int, float, float) method.
I also decompiled the class file to make sure it had the previous fix applied.

Triggered by a stack of 2 minecraft:rotten_flesh just as before.

Values in the Player Data file:

• foodExhaustionLevel 1.401881
• foodLevel 17
• foodSaturationLevel 0.2000003
• foodTickTimer 0
• Health 17

Thanks for all the info, really need to get this one figured out.

EDIT: More info:

2x rotten_flesh stack has the following FoodValues:

hunger = 4
saturationModifier = 0.1
getSaturationIncrement = 0.8

Which means with the player data in the OP, I believe getEstimatedHealthIncrement(int, float, float) is being called with:

foodLevel = Math.min(17 + 4, 20) = 20
saturationLevel = Math.min(0.2000003 + 0.8, 20) = 1.0000003
exhaustionLevel = 1.401881

Okay, I think I've figured out the problem:

Inside this conditional, we increment exhaustionLevel by limitedSaturationLevel:

It's possible, though, for limitedSaturationLevel to be extremely small, i.e. 1.4E-45, and, due to how floating point works, that can be small enough that exhaustionLevel doesn't actually change representation from the increment (exhaustionLevel + limitedSaturationLevel == exhaustionLevel). Therefore, we enter an infinite loop since exhaustionLevel is no longer changing at all.

Vanilla Minecraft doesn't run into this problem because it just does 1 'iteration' of our getEstimatedHealthIncrement in its FoodStats.update function, so if exhaustion isn't incremented in a given update it's not a problem (future player actions will change saturation/exhaustion which changes how update works).

I believe we can fix this by treating close-to-zero exhaustion/saturation levels as zero, or otherwise ensuring that we handle close-to-zero values in a safer way.

I think limitedSaturationLevel because it's too small that the number of loops has become very bigger(pseudo-infinite loops)

I think limitedSaturationLevel because it's too small that the number of loops has become very bigger(pseudo-infinite loops)

It's a real infinite loop. Here's a test case that reproduces it:

    @Test
    public void testEstimatedHealth() {
        int foodLevel = 20;
        float saturationLevel = Float.intBitsToFloat(0x0000001);
        float exhaustionLevel = Float.intBitsToFloat(0x1000000);
        float healthIncrement = FoodHelper.getEstimatedHealthIncrement(foodLevel, saturationLevel, exhaustionLevel);
    }

If saturationLevel is 1000 times smaller than exhaustionForRegen, there will be no obvious variant of recovered health. We can ignore it

Will be fixed by c44304e (Fabric) and b563b91 (Forge)

Testing this also made me realize that there's the potential for a massive improvement in the worst-case performance of this function. The worst case number of iterations of the main loop of the function has gone from millions down to around 18.

Thanks again for the detailed report of this bug @TigerWalts!