don't try to test module path if we can't load the module #57590
Conversation
|
Tagging subscribers to this area: @dotnet/area-system-diagnostics-process Issue Detailsfixes #57452
|
| if (moduleHandle == IntPtr.Zero) | ||
| { | ||
| Assert.Equal(126, Marshal.GetLastWin32Error()); // ERROR_MOD_NOT_FOUND | ||
| Assert.Equal(Architecture.X86, RuntimeInformation.ProcessArchitecture); |
There was a problem hiding this comment.
Should we keep this assert or is it unstable as well?
There was a problem hiding this comment.
I was hoping that 126 (ERROR_MOD_NOT_FOUND) is the only error we can get from LoadLibrary, but from the log that you have provided it seems that this syscall can fail with other errors as well.
FWIW in this particular case it failed with ERROR_INSUFFICIENT_BUFFER (The data area passed to a system call is too small) while we don't pass any buffers to the syscall (assuming that we don't threat the valid path as buffer)
There was a problem hiding this comment.
Just to clarify, I was referring to the Assert from line 40
| IntPtr moduleHandle = Interop.Kernel32.LoadLibrary(longNamePath); | ||
| if (moduleHandle == IntPtr.Zero) | ||
| { | ||
| Assert.Equal(126, Marshal.GetLastWin32Error()); // ERROR_MOD_NOT_FOUND |
There was a problem hiding this comment.
could we bring back this assert in 7.0 and expand it to handle 122 (the error in helix)?
|
dotnet-linker-tests (Build Browser wasm release Runtime_Release) and runtime-dev-innerloop (Build Linux x64 release SourceBuild) are nuget restore issues. |
ghost
locked as resolved and limited conversation to collaborators
3 participants
fixes #57452