Panic when sleeping until far into the future

[Erk-]

Version

At least 1.21.2 and current git master

Platform

Linux archlinux 6.0.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 03 Nov 2022 18:01:58 +0000 x86_64 GNU/Linux

Description

Panic when sleeping until far into the future (though not if it is too far)

I tried this code:

#[tokio::test]
async fn t() {
    // u64::MAX will work as expected.
    let big = std::time::Duration::from_secs(u64::MAX/10);
    tokio::time::sleep(big).await;
}

Playground

I expected to see this happen: Nothing, in that it would just sleep

Instead, this happened:
In debug it hits a debug assertion:

thread 't' panicked at 'assertion failed: timestamp < STATE_MIN_VALUE', /home/valdemar/.cargo/git/checkouts/tokio-377c595163f99a10/9e3fb16/tokio/src/runtime/time/entry.rs:239:9

In release mode it hits another panic:

thread 't' panicked at 'Timer already fired', /home/valdemar/.cargo/git/checkouts/tokio-377c595163f99a10/9e3fb16/tokio/src/runtime/time/entry.rs:398:9

Extra context

This seems to be similar to the issue solved by #4495.

But it seems that the use of u64::MAX causes issues because it is used as signal values.

The issue seems to be resolve by changing the value here into u64::MAX - 1, but I am not sure if that is the best way to resolve this issue, given it also seem to be used as a signal value here.

[Simon-Laux]

The issue seems to be resolve by changing the value here into u64::MAX - 1, but I am not sure if that is the best way to resolve this issue, given it also seem to be used as a signal value here.

Could u64::MAX - 2 work then? I think it would make sense to define whatever is used as maximum in the end as constant.

[Erk-]

The issue seems to be resolve by changing the value here into u64::MAX - 1, but I am not sure if that is the best way to resolve this issue, given it also seem to be used as a signal value here.

Could u64::MAX - 2 work then? I think it would make sense to define whatever is used as maximum in the end as constant.

Yeah that is how I have solved it, but I had not made a pr because the test I have added blocks indefinitely.

I have opened a PR with a solution to the bug, but with the broken test in #5710.

[Erk-]

This was fixed in #5710