You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
OSX failure on StringTests.StartsWithNoMatch_StringComparison #112195
Build: 🔎https://dev.azure.com/dnceng-public/public/_build/results?buildId=940013 Error message validated:[[FAIL] System.Tests.StringTests.StartsWithNoMatch_StringComparison] Result validation: ❌ Known issue did not match with the provided build. Validation performed at: 2/5/2025 4:19:32 PM UTC
Analysis: Root cause identifiable from code inspection
A dump or repro isn't strictly necessary here — this is a wrong-return-value bug, not a crash, so a dump wouldn't add much. The root cause is identifiable from the code.
What the test does
The test (StartsWithNoMatch_StringComparison) creates strings from chars \u0001–\u0096 (control characters + basic Latin), introduces a single-char mismatch at each position, then asserts that culture-aware StartsWith returns consistent results between calls:
The failure (Expected: True, Actual: False) means the same underlying comparison returns different results on different invocations for the same input.
The intermittent nature suggests Apple's precomposedStringWithCanonicalMapping (NFC normalization) or [NSString compare:options:range:locale:] is non-deterministic for strings containing low Unicode code points — particularly the C1 control character range (\u0080–\u009F).
Suggested next step
Rather than trying to obtain a dump, enhance the test with diagnostic output to capture the exact failing parameters:
Re-enable on Apple mobile and wait for CI to capture the specific (length, mismatchIndex, StringComparison) combination. That would clarify whether the issue is in NFC normalization of specific control chars or non-deterministic NSString comparison, and whether a workaround in pal_collation.m is feasible vs. filing an Apple bug.
The Helix queue configs show this has reproduced across multiple macOS versions:
Timeframe
Helix Queue
macOS Version
Oct 2024 (first failure)
OSX.1200.Amd64.Open
macOS 12 Monterey
Mar 2026 (latest hit, build 1316114)
OSX.15.Amd64.Open
macOS 15 Sequoia
This spans 17+ months across macOS 12 through 15, so it's not a regression in a specific Apple release — it's a long-standing behavior in Apple's [NSString compare:options:range:locale:] or precomposedStringWithCanonicalMapping for low Unicode code points (control characters).
Activity
dotnet-policy-service commentedon Feb 5, 2025
Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.
dotnet-policy-service commentedon Feb 5, 2025
Tagging subscribers to this area: @dotnet/area-system-globalization
See info in area-owners.md if you want to be subscribed.
tarekgh commentedon Feb 5, 2025
@matouskozak please triage. Thanks!
matouskozak commentedon Feb 6, 2025
Looks like duplicate of #108832 but with slightly different error message. fyi: @kotlarmilos
2 remaining items
dotnet-policy-service commentedon Feb 6, 2025
Tagging subscribers to 'os-tvos': @vitek-karas, @kotlarmilos, @ivanpovazan, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.
dotnet-policy-service commentedon Feb 6, 2025
Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @ivanpovazan, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.
danmoseley commentedon Mar 22, 2026
Note
This analysis was generated by GitHub Copilot.
Analysis: Root cause identifiable from code inspection
A dump or repro isn't strictly necessary here — this is a wrong-return-value bug, not a crash, so a dump wouldn't add much. The root cause is identifiable from the code.
What the test does
The test (
StartsWithNoMatch_StringComparison) creates strings from chars\u0001–\u0096(control characters + basic Latin), introduces a single-char mismatch at each position, then asserts that culture-awareStartsWithreturns consistent results between calls:The failure (
Expected: True, Actual: False) means the same underlying comparison returns different results on different invocations for the same input.Where it goes wrong
On Apple mobile in hybrid globalization mode, culture-aware
StartsWithroutes throughGlobalizationNative_StartsWithNativeinpal_collation.m:The intermittent nature suggests Apple's
precomposedStringWithCanonicalMapping(NFC normalization) or[NSString compare:options:range:locale:]is non-deterministic for strings containing low Unicode code points — particularly the C1 control character range (\u0080–\u009F).Suggested next step
Rather than trying to obtain a dump, enhance the test with diagnostic output to capture the exact failing parameters:
Re-enable on Apple mobile and wait for CI to capture the specific
(length, mismatchIndex, StringComparison)combination. That would clarify whether the issue is in NFC normalization of specific control chars or non-deterministicNSStringcomparison, and whether a workaround inpal_collation.mis feasible vs. filing an Apple bug.danmoseley commentedon Mar 22, 2026
Note
This analysis was generated by GitHub Copilot.
Not specific to a particular Apple OS version
The Helix queue configs show this has reproduced across multiple macOS versions:
OSX.1200.Amd64.OpenOSX.15.Amd64.OpenThis spans 17+ months across macOS 12 through 15, so it's not a regression in a specific Apple release — it's a long-standing behavior in Apple's
[NSString compare:options:range:locale:]orprecomposedStringWithCanonicalMappingfor low Unicode code points (control characters).danmoseley commentedon Mar 22, 2026
@kotlarmilos is this proposed tracing worth adding to the test to find out more?
kotlarmilos commentedon Mar 23, 2026
Yes this is sound, let's give it a try
Fix intermittent OSX CI failures in StartsWithNoMatch_StringCompariso…
Fix intermittent OSX CI failures in StartsWithNoMatch_StringCompariso…