runtime: Test failure WindowsAlternateDataStreamOverwrite
Run: runtime-coreclr libraries-jitstress 20230319.1
Failed test:
net8.0-windows-Release-arm64-CoreCLR_checked-jitminopts-Windows.11.Arm64.Open
- System.IO.Tests.File_Copy_str_str_b.WindowsAlternateDataStreamOverwrite(defaultStream: \"::$DATA\", alternateStream: \":bar:$DATA\")
- System.IO.Tests.File_Copy_str_str_b.WindowsAlternateDataStreamOverwrite(defaultStream: \"::$DATA\", alternateStream: \":bar\")
- System.IO.Tests.File_Copy_str_str_b.WindowsAlternateDataStreamOverwrite(defaultStream: \"\", alternateStream: \":bar:$DATA\")
- System.IO.Tests.File_Copy_str_str_b.WindowsAlternateDataStreamOverwrite(defaultStream: \"\", alternateStream: \":bar\")
- System.IO.Tests.FileInfo_CopyTo_str_b.WindowsAlternateDataStreamOverwrite(defaultStream: \"::$DATA\", alternateStream: \":bar:$DATA\")
... ...
Error message:
System.IO.IOException : The parameter is incorrect. : 'C:\h\w\A6E40946\t#File_Copy_str_str_b_bq13ehkl.mbj\WindowsAlternateDataStreamOverwrite_330_kaeldovu\WindowsAlternateDataStreamOverwrite_331_pdfk8999:bar:$DATA'
Stack trace
at System.IO.FileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite) in /_/src/libraries/System.Private.CoreLib/src/System/IO/FileSystem.Windows.cs:line 84
at System.IO.Tests.File_Copy_str_str_b.Copy(String source, String dest, Boolean overwrite) in /_/src/libraries/System.IO.FileSystem/tests/File/Copy.cs:line 267
at System.IO.Tests.File_Copy_str_str_b.WindowsAlternateDataStreamOverwrite(String defaultStream, String alternateStream) in /_/src/libraries/System.IO.FileSystem/tests/File/Copy.cs:line 346
at InvokeStub_File_Copy_str_str_b.WindowsAlternateDataStreamOverwrite(Object, Object, IntPtr*)
at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)
{
"ErrorMessage": "",
"BuildRetry": false,
"ErrorPattern": "System.IO.IOException : The parameter is incorrect.*WindowsAlternateDataStreamOverwrite",
"ExcludeConsoleLog": false
}
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=314956 Result validation: ✅ Known issue matched with the provided build.
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 1 | 1 | 11 |
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 22 (21 by maintainers)
Another data point: it frequently fails in runtime as part of NAOT runs too: https://runfo.azurewebsites.net/search/tests/?q=started%3A~7+definition%3Aruntime+name%3ASystem.IO.Tests.File_Copy_str_str_b.WindowsAlternateDataStreamOverwrite
@adamsitnik This is unlikely to an interop issue. I disagree with your analysis based on the above (2) statements.
Since all interop stub logic is idempotent, the first (1) and all subsequent operations run the same code. It is unlikely therefore that if the first succeeds and the second fails it has anything to do with the interop stub itself.
The second doesn’t indicate anything to do with marshalling since interop generates IL and is platform agnostic - other than pointer size, in all cases I can think of. Also, since this is passing on the first run the IL and all interop code is identical across runs.
It is entirely possible there is a codegen issue, which we should consider. However, this is File I/O and based on the path in the failure it is entirely possible the Win32 File API is doing something the test isn’t handling.
'C:\h\w\BDDE0A0A\t#File_Copy_str_str_b_snfjrv1o.lza\WindowsAlternateDataStreamOverwrite_330_xpdes8ds\WindowsAlternateDataStreamOverwrite_331_2j4b3v36:bar:$DATA'In summary I don’t think there is enough data to warrant sending this over to the interop team or any other runtime team at present. The owner of the File IO APIs should be able to run this on a Windows ARM64 machine and see if they can reproduce it and perhaps collect a bit more information.
Based on the data presented so far, it is most likely Windows Arm64 specific OS issues. area-System.IO owners should investigate it and file a bug against the OS team as appropriate.
Also, I would check for potential machine setup issue. It is possible that the file system is misconfigured on some of the Windows Helix machines that makes the test fail.
FWIW: There are other tests using alternate data stream paths and they didn’t fail. Only CopyFileEx with overwrite: true fails. I don’t know what JitStress may be doing that affects this specific scenario.