Skip to content

[release/10.0] Add missing HAVE_CLOCK_MONOTONIC to config.h.in#124121

Open
Copilot wants to merge 1 commit intorelease/10.0from
copilot/backport-runtime-pr-124086
Open

[release/10.0] Add missing HAVE_CLOCK_MONOTONIC to config.h.in#124121
Copilot wants to merge 1 commit intorelease/10.0from
copilot/backport-runtime-pr-124086

Conversation

Copy link
Contributor

Copilot AI commented Feb 7, 2026

Backport of #124086 to release/10.0

Customer Impact

  • Customer reported
  • Found internally

Task.Delay and other timing operations freeze indefinitely when system time is adjusted backwards on Linux in .NET 10. Reported by two different customers.

Regression

  • Yes
  • No

Add missing #cmakedefine01 HAVE_CLOCK_MONOTONIC to src/coreclr/pal/src/config.h.in. While CMake successfully detects monotonic clock support, the configuration value is never propagated to the generated config.h header. This causes the runtime to incorrectly fall back to wall-clock time (CLOCK_REALTIME) instead of using monotonic clocks (CLOCK_MONOTONIC),

Testing

Customer confirmed the issue is fixed using private build

Risk

Minimal - one-line CMake configuration fix restoring .NET 8/9 behavior.

@jkotas
Copy link
Member

jkotas commented Feb 7, 2026

@copilot Try again

Copy link
Contributor Author

Copilot AI commented Feb 7, 2026

@copilot Try again

I've created commit 4f20351 with the fix (adding HAVE_CLOCK_MONOTONIC to config.h.in) based on release/10.0, and updated the PR description to follow the servicing template. However, I cannot force-push due to incompatible branch histories (origin/copilot branch is based on main, but needs to be based on release/10.0). The PR base branch also needs to be manually changed from main to release/10.0 in the GitHub UI.

Fixes issue #123950 where Task.Delay freezes when system time jumps
backwards on .NET 10 Linux - a regression from .NET 8 and 9.

The root cause was a missing `#cmakedefine01 HAVE_CLOCK_MONOTONIC`
directive in `src/coreclr/pal/src/config.h.in`. While CMake was
successfully detecting monotonic clock support, the configuration value
was never propagated to the generated config.h header. This caused the
runtime to fall back to wall-clock time (CLOCK_REALTIME) instead of
monotonic clocks (CLOCK_MONOTONIC), making timing operations vulnerable
to system time adjustments.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: jkotas <6668460+jkotas@users.noreply.github.com>
@dotnet-policy-service dotnet-policy-service bot added the linkable-framework Issues associated with delivering a linker friendly framework label Feb 7, 2026
@jkotas jkotas changed the base branch from main to release/10.0 February 7, 2026 03:51
@jkotas jkotas changed the title [WIP] Backport changes from PR 124086 to release 10.0 [release/10.0] Add missing HAVE_CLOCK_MONOTONIC to config.h.in Feb 7, 2026
@jkotas jkotas marked this pull request as ready for review February 7, 2026 04:02
Copilot AI review requested due to automatic review settings February 7, 2026 04:02
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Backports the fix for a .NET 10 Linux regression where timing operations (e.g., Task.Delay) can hang indefinitely if the system clock is adjusted backwards, by ensuring CMake’s monotonic clock detection is propagated into the generated PAL config header.

Changes:

  • Add the missing #cmakedefine01 HAVE_CLOCK_MONOTONIC to the PAL config.h.in template so HAVE_CLOCK_MONOTONIC is correctly emitted into config.h.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-System.Threading linkable-framework Issues associated with delivering a linker friendly framework

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants