Task.Delay freezes on DateTime jumps

[hlippke]

Description

When using Task.Delay, the runtime freezes if the time is set backwards.

Reproduction Steps

Run the following code:

// See https://aka.ms/new-console-template for more information

using System;
using System.Threading.Tasks;

var counter = 0;
while (true)
{
    await Task.Delay(TimeSpan.FromSeconds(1));
    Console.WriteLine($"{DateTime.Now:s}: {++counter:0000}");
}

And set the time back, e.g. using sudo date -s "2026-02-03 17:29:00".

Expected behavior

Monotonic output of the DateTime and counter

Actual behavior

Output stops, ie. Task.Delay does not return until the original time (+1s in this example) is reached

Regression?

This works in .net 8 and 9 on Linux and on all .net recent versions running on Windows.

Known Workarounds

No response

Configuration

.net runtime 10.0.0
SDK 10.0.102
Manjaro Linux 6.12.68-1 on VirtualBox 7.1.6 x64

and
.net runtime 10.0.2
SDK 10.0.102
Yocto Linux 6.11.4-fslc-fslc-g0ed66f981bd8 #1 SMP PREEMPT Mon Oct 21 14:14:25 UTC 2024 armv7l GNU/Linux

Other information

I have failed to find any means to sleep using a monotonic time source. System.Threading.Timer, PeriodicTimer, Thread.Sleep, ManualResetEventSlim.Wait - all are showing the same effect.

I was able to create a platform dependent wait method using poll from libc via P/Invoke

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• Task.Delay hangs indefinitely on Linux ARM32 when system clock is set backwards (.NET 10 regression) #122788

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[hlippke]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• Task.Delay hangs indefinitely on Linux ARM32 when system clock is set backwards (.NET 10 regression) #122788

Could indeed be considered a duplicate, although the original issue states that it doesn't happen on x64 Ubuntu whereas I was able to reproduce on Manjaro x64

[tannergooding]

Timers just use Environment.TickCount64 which on Linux resolves down to minipal_lowres_ticks.

On Unix (non-Windows) this picks one of:

• clock_gettime_nsec_np (MacOS)
• clock_gettime with one of:
  • CLOCK_MONOTONIC_COARSE
  • CLOCK_MONOTONIC

None of these should be impacted by manual clock adjustments

A nonsettable system-wide clock that represents monotonic time since—as described by POSIX—"some unspecified point in the past". On Linux, that point corresponds to the number of seconds that the system has been running since it was booted.

The CLOCK_MONOTONIC clock is not affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), but is affected by the incremental adjustments performed by adjtime(3) and NTP. This clock does not count time that the system is suspended. All CLOCK_MONOTONIC variants guarantee that the time returned by consecutive calls will not go backwards, but successive calls may—depending on the architecture—return identical (not-increased) time values.

Its possibly that one of these platforms is doing something non-compliant or that another part of the system is incorrectly depending on a different time source, but that would require someone who can reproduce the issue to go and debug the underlying issue and try to find out where the stall is (the runtime is likely not frozen but just waiting).

[hlippke]

It surely is waiting.
Please note that charging back an forth between .net 10 and .net 9 runtime shows different results, all else kept equal: .net 9 continues to run above example while .net 10 stalls until the original time is reached.

Could reproduce in otherwise unchanged Manjaro and Yocto build.

[tannergooding]

Do you have the ability to set a breakpoint during such a stall and to get the stack trace for each thread, to help try to root cause what might be waiting? This would help root cause if something is incorrectly relying on system time rather than the monotonic time source.

[hlippke]

Not at the office right now but I can break while it's waiting and share the results tomorrow.

I already did exactly that today but can't remember the exact method.

Will also try strace

[hlippke]

Using the above code and commandline to reproduce the stall, then hit "Pause" in the debugger.
Stacks:

 @3220

 @3224

 @3219

 @3225

.NET Timer @3228
	WaitHandle.WaitOneNoCheck()
	TimerQueue.TimerThread()
	Thread.StartCallback()
	[Native to Managed Transition]

.NET TP Gate @3242
	WaitHandle.WaitOneNoCheck()
	PortableThreadPool.GateThread.GateThreadStart()
	Thread.StartCallback()
	[Native to Managed Transition]

.NET TP Worker @3241
	LowLevelLifoSemaphore.WaitNative()
	LowLevelLifoSemaphore.WaitForSignal()
	PortableThreadPool.WorkerThread.WorkerThreadStart()
	Thread.StartCallback()
	[Native to Managed Transition]

Main Thread @3204
	Monitor.Wait() at /home/henning/.config/JetBrains/Rider2025.3/resharper-host/DecompilerCache/decompiler/e7f701bc05fe4c4c938e43df30078ba3dba800/1d/0dd4a43b/Monitor.cs:line 270
	ManualResetEventSlim.Wait()
	Task.SpinThenBlockingWait()
	Task.InternalWaitCore()
	Task.InternalWait()
	TaskAwaiter.HandleNonSuccessAndDebuggerNotification()
	Program.<Main>()

Looks like the Timer is stuck at WaitHandle.WaitOneNoCheck()

[wjohnstonsolventum]

If helpful, I see the same issue, and in digging, I can reproduce it with this:

var timerEvent = new AutoResetEvent(false);
while (true)
{
    Console.WriteLine($"Current tick count: {Environment.TickCount64}");
    timerEvent.WaitOne(1000);
}

As described, the every second printout stops when I set the clock to a time in the past, and then resumes when I set the clock to the current time. I can reproduce this on an arm64 Yocto device, an arm64 Ubuntu VM in VirtualBox, and an x64 Ubuntu VM in VirtualBox.

[tannergooding]

CC. @jkoritzinsky since you've touched a lot of the wait subsystem code recently (for .NET 11) and may have some input

I'm looking through the logic for WaitHandle.WaitOneNoCheck() (in .NET 10) and it looks to all route down through WaitableObject.Wait, which itself uses ThreadWaitInfo.Wait. That in turn uses LowLevelMonitor.Wait and check Environment.TickCount for the required time to be passed. -- Notably not Environment.TickCount64 notably, so there is theoretical overflow risk, but I doubt that's what's happening here.

It looks like the issue is potentially that LowLevelMonitor.Wait itself goes through SystemNative_LowLevelMonitor_TimedWait which just calls pthread_cond_timedwait_relative_np on MacOS, but on Unix calls clock_gettime(CLOCK_MONOTONIC) only if HAVE_PTHREAD_CONDATTR_SETCLOCK and CLOCK_MONOTONIC are defined and otherwise falls back to gettimeofday. -- Noting this probably should be using the same clock as Environment.TickCount64 if possible, which is sometimes CLOCK_MONOTONIC_COARSE instead

The default on Linux appears to be documented as CLOCK_REALTIME if pthread_condattr_setclock isn't used, which would also be prone to the same time shifts as gettimeofday and so simply avoiding gettimeofday isn't "sufficient", but may help solve some types of problems depending on which clock is modified.

I notably don't see any meaningful changes here between .NET 8 and .NET 10, but perhaps something else changes that I'm not seeing.

[tannergooding]

The official Linux binaries do look to be using pthread_cond_timedwait and pthread_condattr_setclock, so they "shouldn't" be hittin gthe timeofday path.

But that's the only place I see that things could be getting messed up.