-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test failure System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.Add_File(format: Gnu) #69474
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @dotnet/area-system-io-compression Issue DetailsRun: runtime-coreclr libraries-jitstress 20220517.1 Failed test:
Error message:
No kusto information.
|
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsRun: runtime-coreclr libraries-jitstress 20220517.1 Failed test:
Error message:
No kusto information.
|
Failed in #69948 This is failing often enough to deserve blocking-clean-ci label. |
Also failed in #69838. Different test, but likely the same problem (the seconds are off by one): Exception Message Assert.Equal() Failure Stack Trace at System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.VerifyPlatformSpecificMetadata(String filePath, TarEntry entry) in //src/libraries/System.Formats.Tar/tests/TarWriter/TarWriter.WriteEntry.File.Tests.Unix.cs:line 195 |
The Kusto query tells me this is happening in:
Jobs
| project JobId, Source, Build, Started, Type
| where Started > ago(15d)
| where Type startswith "test/functional/cli/innerloop"
| where Source == "pr/public/dotnet/runtime/refs/heads/main" or Source startswith "pr/public/dotnet/runtime/refs/pull"
| join kind=inner
(TestResults | project Result, WorkItemId, JobId, WorkItemFriendlyName, Method, StackTrace, WorkItemName) on JobId
| where Result == "Fail"
| where Method == "Add_File"
| where WorkItemFriendlyName == "System.Formats.Tar.Tests"
| where StackTrace has "VerifyPlatformSpecificMetadata"
| join kind=inner
(WorkItems | project WorkItemId, QueueName) on WorkItemId There are 22 hits in the last 30 days. As Michal mentioned, the test is failing because the timestamp comparison is differing by one second. This is strange, because the archive entry's timestamp that is converted from integer to Update: Pushed PR #69997 to disable the test to unblock PRs. |
removing label as test was disabled. |
Failed again in: runtime-coreclr libraries-jitstressregs 20220612.1 Failed test:
Error message:
|
I haven't looked in detail but it looked like whatever we're validating here was roundripped through a floating-point number in the TAR file format - that raises a red flag around precisions and off-by-one roundings. It should be possible to validate this is caused by rounding by roundtripping all possible integer timestamps within one second through the file format and seeing what comes out on the integer side again. |
Thank you, @MichalStrehovsky. I am currently working on changing all the tar tests to avoid expecting exact values. But I will also test what you're suggesting, in case the conversion logic from/to DateTimeOffset/double is wrong. |
There may be a bug for certain values, but it is worth noting that guaranteeing roundtripping for |
Another similarly looking failure in System.Formats.Tar.Tests.V7TarEntry_Conversion_Tests.Constructor_ConversionGnu_BackAndForth_SymbolicLink:
There are several tests with this failure mode, but only one of them got disabled. #69997 (comment) The latest one hit in https://dev.azure.com/dnceng/public/_build/results?buildId=1835642&view=logs&jobId=ee1d0ee6-ff1e-56e7-4a8c-87d1cd9cc235. I'm putting back blocking clean CI label. |
Failed again in: runtime-coreclr libraries-jitstress 20220621.1 Failed test:
Error message:
|
Run: runtime-coreclr libraries-jitstress 20220517.1
Failed test:
Error message:
No kusto information.
The text was updated successfully, but these errors were encountered: