[main] Update dependencies from dotnet/roslyn-analyzers

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/roslyn-analyzers

• Subscription: 5465c78f-1281-49a8-f9b0-08d9301a7704
• Build: 20240805.1
• Date Produced: August 6, 2024 7:56:45 AM UTC
• Commit: 3211f48253bc18560156d90dc5e710d35f7d03fa
• Branch: refs/heads/main

• Updates:
  • Microsoft.CodeAnalysis.Analyzers: from 3.11.0-beta1.24402.1 to 3.11.0-beta1.24405.1
  • Microsoft.CodeAnalysis.NetAnalyzers: from 9.0.0-preview.24402.1 to 9.0.0-preview.24405.1

[lewing]

  at System.Delegate.<BindToMethodInfo>g____PInvoke|21_0(System.Runtime.CompilerServices.ObjectHandleOnStack, System.Runtime.CompilerServices.ObjectHandleOnStack, System.RuntimeMethodHandleInternal, System.Runtime.CompilerServices.QCallTypeHandle, System.DelegateBindingFlags)
   at System.Reflection.RuntimeMethodInfo.CreateDelegateInternal(System.Type, System.Object, System.DelegateBindingFlags)
   at System.Linq.Expressions.Interpreter.FuncCallInstruction`2[[System.__Canon, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.Int32, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]..ctor(System.Reflection.MethodInfo)
   at System.RuntimeMethodHandle.InvokeMethod(System.Object, Void**, System.Signature, Boolean)
   at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(System.Object, System.Span`1<System.Object>, System.Reflection.BindingFlags)
   at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.Reflection.RuntimeConstructorInfo.Invoke(System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.RuntimeType.CreateInstanceImpl(System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at System.Activator.CreateInstance(System.Type, System.Object[])

cc @jeffschwMSFT

[lewing]

@mangod9 this looks like reflection and not related to the flow but I didn't want to open a known issue without checking

[mangod9]

Adding @ericstj who owns reflection. I havent seen this particular failure before. Is it consistent?

[ericstj]

This is in the VM:

runtime/src/coreclr/vm/comdelegate.cpp

Line 992 in 4bd1492

extern "C" BOOL QCALLTYPE Delegate_BindToMethodInfo(QCall::ObjectHandleOnStack d, QCall::ObjectHandleOnStack target,

There's a log with dump analysis
https://helixre107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-pull-106072-merge-835c24e1c7e8458e8f/System.Linq.Expressions.Tests/1/console.27df0834.log?helixlogtype=result

It claims an access violation here:

(778.1de4): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
*** WARNING: Unable to verify checksum for coreclr.dll
coreclr!Stub::HasExternalEntryPoint [inlined in coreclr!COMDelegate::BindToMethod+0xcb]:
00007ffb`fc169d63 f7400400000040  test    dword ptr [rax+4],40000000h ds:00007ffb`9e30f004=????????

(Inline Function) --------`-------- coreclr!Stub::HasExternalEntryPoint
(Inline Function) --------`-------- coreclr!Stub::GetEntryPointInternal
(Inline Function) --------`-------- coreclr!Stub::GetEntryPoint
00000017`93e7b510 00007ffb`fc16a0d8 coreclr!COMDelegate::BindToMethod+0xcb

Can someone from runtimne have a look? @jkotas @AaronRobinsonMSFT

[ericstj]

Seems like same symptom as #55536.

I wish we had the dump here - it seems like it wasn't uploaded @carlossanlop @hoyosjs

[AaronRobinsonMSFT]

Taking a look.

[jkotas]

I think it is a regression introduced by #105480 .

[jkotas]

I think it is a regression introduced by #105480 .

Pushed a revert

[hoyosjs]

@ericstj - I see a dump dotnet.exe.7864.dmp and for your particular one dotnet.exe.1912.dmp

[ericstj]

@ericstj - I see a dump dotnet.exe.7864.dmp and for your particular one dotnet.exe.1912.dmp

Huh, for some reason I couldn't see in the test tab, nor would runfo pull it down. How did you find that?

[mangod9]

@ericstj - I see a dump dotnet.exe.7864.dmp and for your particular one dotnet.exe.1912.dmp

Huh, for some reason I couldn't see in the test tab, nor would runfo pull it down. How did you find that?

@cshung had also hit an issue where the dump was not available where it should have been collected. Perhaps some generic issue here?

[jkotas]

Huh, for some reason I couldn't see in the test tab, nor would runfo pull it down. How did you find that?

If you did not see the test tab, it is a problem in AzDo. The AzDo is responsible to show the test tab.

I can see the test tab fine for the both the Windows and Linux crashes earlier, and runfo command worked fine too.

https://dev.azure.com/dnceng-public/public/_build/results?buildId=768489&view=ms.vss-test-web.build-test-results-tab&runId=19613134&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab&resultId=218254

https://dev.azure.com/dnceng-public/public/_build/results?buildId=768489&view=ms.vss-test-web.build-test-results-tab&runId=19614930&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab&resultId=218646

@cshung had also hit an issue where the dump was not available where it should have been collected. Perhaps some generic issue here?

We have several generic issues with collecting dumps (e.g. dumps not collected for build crashes). There are tracking issues opened for the known generic issues. But I do not see an issue with collecting crash dumps in this PR.

[jkotas]

All failures are known issues according to the build analysis