-
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 WindowsAlternateDataStreamOverwrite #83659
Comments
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsRun: runtime-coreclr libraries-jitstress 20230319.1 Failed test:
Error message:
|
Hi @v-wenyuxu thanks, please put test name not url in the title. |
FWIW: There are other tests using alternate data stream paths and they didn't fail. |
Failed in https://dev.azure.com/dnceng-public/public/_build/results?buildId=250159&view=results again (in the zapdisable scenario, so there is no special JIT modes enabled there). |
Failed again in: runtime-coreclr libraries-jitstress 20230519.1 Failed test:
Error message:
|
The error The logic around the sys-call seems very simple: runtime/src/libraries/Common/src/Interop/Windows/Kernel32/Interop.CopyFile.cs Lines 11 to 15 in e91db04
If we had a bug in System.IO, we would get it almost always. And it the provided logs I can see that it's throw on the second call to this sys-call (the first worked fine): runtime/src/libraries/System.IO.FileSystem/tests/File/Copy.cs Lines 336 to 346 in e91db04
Since it's specific to Windows arm64, I suspect that it's either a marshalling or runtime bug. @jkotas what do you think? |
Tagging subscribers to this area: @dotnet/interop-contrib Issue DetailsRun: runtime-coreclr libraries-jitstress 20230319.1 Failed test:
Error message:
|
@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.
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. |
Ugh. This is a JIT stress issue. Nevermind, the codegen team needs to take a look. |
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsRun: runtime-coreclr libraries-jitstress 20230319.1 Failed test:
Error message:
|
@dotnet/jit-contrib Is there anything the owner of this test could collect that would help with the investigation? |
As I pointed out above the failure was in the jitminopts scenario and the recent one is in zapdisable. There's no abnormal jit stress enabled in these scenarios; the first one is like running debug codegen, the second one is like running without R2R. Is there any reason to believe this is a codegen issue? Have we tried reproducing the issue with the paths involved? |
Ah. I missed that this was reproducing on a different leg as well. Apologies.
Not from my end. I naively set it to that since it was marked "JitStress".
+1 /cc @adamsitnik |
Another data point: it frequently fails in runtime as part of NAOT runs too: https://runfo.azurewebsites.net/search/tests/?q=started%3A%7E7+definition%3Aruntime+name%3ASystem.IO.Tests.File_Copy_str_str_b.WindowsAlternateDataStreamOverwrite |
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. |
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsRun: runtime-coreclr libraries-jitstress 20230319.1 Failed test:
Error message:
|
Thank you all for your feedback, I am going to try to repro it on my Windows x64 and arm64 machines. |
@jozkee @adamsitnik This issue is marked as both "blocking-clean-ci-optional" and "Milestone: Future". That doesn't make sense. If it's actually blocking, it should be in the current release milestone. If it's not blocking, remove the blocking label. |
This is failing in Native AOT now as well. Since jitstress saw this first it would be good if someone from JIT could take a look. |
@agocke Do you have any new evidence to suggest this is a JIT issue? I do not believe this is a JIT issue -- please see the comments above for context. |
Added this to the 9.0.0 milestone because of the frequency |
Another set of failures here: https://dev.azure.com/dnceng-public/public/_build/results?buildId=487061&view=ms.vss-test-web.build-test-results-tab |
I adjusted the KnownBuildError pattern. It was not catching many hits. I found this in a 7.0 PR: #98223
|
Hit in #100233 |
@dotnet/area-system-io An unrealted deps flow PR hit this failure in 8.0:
|
Run: runtime-coreclr libraries-jitstress 20230319.1
Failed test:
Error message:
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=675511
Error message validated:
[System.IO.Tests.File_Copy_str_str_b.WindowsAlternateDataStreamOverwrite
]Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 5/16/2024 10:38:57 PM UTC
Report
Summary
Known Issue Error Message
Fill the error message using step by step known issues guidance.
The text was updated successfully, but these errors were encountered: