Test failure System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.Add_File(format: Pax)

[VincentBu]

Run: runtime-coreclr libraries-jitstress 20220531.1

Failed test:

net7.0-windows-Release-arm64-CoreCLR_checked-jitstress2_tiered-Windows.10.Arm64v8.Open

- System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.Add_File(format: Pax)

Error message:

Assert.Equal() Failure
Expected: 34
Actual:   33


Stack trace
   at System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.VerifyTimestamp(DateTime expected, DateTimeOffset actual) in /_/src/libraries/System.Formats.Tar/tests/TarWriter/TarWriter.WriteEntry.File.Tests.Windows.cs:line 76
   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.Windows.cs:line 50
   at System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.Add_File(TarFormat format) in /_/src/libraries/System.Formats.Tar/tests/TarWriter/TarWriter.WriteEntry.File.Tests.cs:line 110
   at InvokeStub_TarWriter_WriteEntry_File_Tests.Add_File(Object, Object, IntPtr*)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

No Kusto information.

[dotnet-issue-labeler]

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.

[carlossanlop]

@VincentBu what is different about the JitStress jobs compared to the normal jobs? I already disabled this test #69997 on Linux, and I'm wondering why is it now failing on Windows as well, but only on JitStress runs.

[vonzshik]

If I'm reading the sources correctly, TarWriter first reads the current info

runtime/src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarWriter.Windows.cs

Lines 49 to 51 in ca2daf1

	entry._header._mTime = new DateTimeOffset(info.LastWriteTimeUtc);
	entry._header._aTime = new DateTimeOffset(info.LastAccessTimeUtc);
	entry._header._cTime = new DateTimeOffset(info.LastWriteTimeUtc); // There is no "change time" property

and only after that accesses the file, which also changes the last access time

runtime/src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarWriter.Windows.cs

Lines 60 to 72 in ca2daf1

	if (entry.EntryType is TarEntryType.RegularFile or TarEntryType.V7RegularFile)
	{
	FileStreamOptions options = new()
	{
	Mode = FileMode.Open,
	Access = FileAccess.Read,
	Share = FileShare.Read,
	Options = FileOptions.None
	};
	Debug.Assert(entry._header._dataStream == null);
	entry._header._dataStream = File.Open(fullPath, options);
	}

If so, that means that the data written into the tar's header might be different from the one the file will have.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Run: runtime-coreclr libraries-jitstress 20220531.1

Failed test:

net7.0-windows-Release-arm64-CoreCLR_checked-jitstress2_tiered-Windows.10.Arm64v8.Open

- System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.Add_File(format: Pax)

Error message:

Assert.Equal() Failure
Expected: 34
Actual:   33


Stack trace
   at System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.VerifyTimestamp(DateTime expected, DateTimeOffset actual) in /_/src/libraries/System.Formats.Tar/tests/TarWriter/TarWriter.WriteEntry.File.Tests.Windows.cs:line 76
   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.Windows.cs:line 50
   at System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.Add_File(TarFormat format) in /_/src/libraries/System.Formats.Tar/tests/TarWriter/TarWriter.WriteEntry.File.Tests.cs:line 110
   at InvokeStub_TarWriter_WriteEntry_File_Tests.Add_File(Object, Object, IntPtr*)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

No Kusto information.

Author:	VincentBu
Assignees:	-
Labels:	arch-arm32, area-System.Runtime, os-windows, JitStress, untriaged, blocking-clean-ci-optional
Milestone:	-

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Run: runtime-coreclr libraries-jitstress 20220531.1

Failed test:

net7.0-windows-Release-arm64-CoreCLR_checked-jitstress2_tiered-Windows.10.Arm64v8.Open

- System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.Add_File(format: Pax)

Error message:

Assert.Equal() Failure
Expected: 34
Actual:   33


Stack trace
   at System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.VerifyTimestamp(DateTime expected, DateTimeOffset actual) in /_/src/libraries/System.Formats.Tar/tests/TarWriter/TarWriter.WriteEntry.File.Tests.Windows.cs:line 76
   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.Windows.cs:line 50
   at System.Formats.Tar.Tests.TarWriter_WriteEntry_File_Tests.Add_File(TarFormat format) in /_/src/libraries/System.Formats.Tar/tests/TarWriter/TarWriter.WriteEntry.File.Tests.cs:line 110
   at InvokeStub_TarWriter_WriteEntry_File_Tests.Add_File(Object, Object, IntPtr*)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

No Kusto information.

Author:	VincentBu
Assignees:	carlossanlop
Labels:	arch-arm32, area-System.IO, os-windows, JitStress, blocking-clean-ci-optional
Milestone:	-

[VincentBu]

@VincentBu what is different about the JitStress jobs compared to the normal jobs? I already disabled this test #69997 on Linux, and I'm wondering why is it now failing on Windows as well, but only on JitStress runs.

I know few about it. I asked tommcdon and he told me that:
JIT Stress is owned by the codegen team (Julie Lee's team). It enables certain JIT features that generate different types of JIT optimizations thereby exercising different code paths in the JIT. If the failure is specific to JIT Stress, it is highly likely a codegen bug. If however the test fails on other runs as well, then it is a bug but not JIT stress specific.

[danmoseley]

@BruceForstall can answer questions about jit stress. Note that libraries tests failures in jit stress are often simply timeouts because it can be slow. (Or perhaps machine configuration specific?)

[BruceForstall]

This might help: https://github.com/dotnet/runtime/blob/main/docs/workflow/ci/triaging-failures.md