[main] Update dependencies from dotnet/installer

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/installer

• Subscription: 2a4e5111-6978-401f-68a5-08dba3b24dbe
• Build: 20240503.16
• Date Produced: May 3, 2024 7:05:39 PM UTC
• Commit: fa261b952d702c6bd604728fcbdb58ac071a22b1
• Branch: refs/heads/main

• Updates:
  • Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.4.24215.2 to 9.0.100-preview.5.24253.16

[lewing]

./RunTests.sh: line 94: 79 Segmentation fault (core dumped) dotnet exec xunit.console.dll Wasm.Build.Tests.dll -xml $XHARNESS_OUT/testResults.xml $HELIX_XUNIT_ARGS -nocolor -verbose -notrait category=IgnoreForCI -notrait category=failing $XUnitTraitArg $RSP_FILE

I'm merging main again but that is a non wasm runtime/xunit bug @jeffschwMSFT

[jeffschwMSFT]

@mangod9 can you take a look? thanks

[mangod9]

Hi @lewing, could you please point me to the link for the dump?

[lewing]

I think the core on https://dev.azure.com/dnceng-public/public/_build/results?buildId=664184&view=ms.vss-test-web.build-test-results-tab&runId=16469844&resultId=100001&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab is the right thing

[mangod9]

Thanks. Here is the stack of the failure. Perhaps related to #101695 -- @dotnet/jit-contrib ?

00 libclrjit!Compiler::optCompactLoop
01 libclrjit!Compiler::optFindLoops
02 libclrjit!Compiler::optFindLoopsPhase
03 libclrjit!jitNativeCode
04 libclrjit!CILJit::compileMethod
05 libcoreclr!invokeCompileMethodHelper
06 libcoreclr!invokeCompileMethod
07 libcoreclr!UnsafeJitFunction
08 libcoreclr!MethodDesc::JitCompileCodeLocked
09 libcoreclr!MethodDesc::JitCompileCodeLockedEventWrapper
0a libcoreclr!MethodDesc::JitCompileCode
0b libcoreclr!MethodDesc::PrepareILBasedCode
0c libcoreclr!TieredCompilationManager::CompileCodeVersion
0d libcoreclr!TieredCompilationManager::DoBackgroundWork
0e libcoreclr!TieredCompilationManager::BackgroundWorkerStart
0f libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper1
10 libcoreclr!ZL31ManagedThreadBase_DispatchOuterP22ManagedThreadCallState
11 libcoreclr!ManagedThreadBase::KickOff
12 libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper0
13 libcoreclr!CorUnix::CPalThread::ThreadEntry

[AndyAyersMS]

Yeah very likely the bug we just fixed. Can we update the 9P5 bits?

[mangod9]

The change seems to be picking up 9.0.100-preview.5.24229.2 but guessing we need something later than that?

[AndyAyersMS]

I think so. The fix is here #101714 so you likely need something stamped 24230 or maybe even one day later (goes up by 50 each month, right? so maybe 24250+).

[mangod9]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

[lewing]

I triggered new flow and merged main

[lewing]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

The darc subscription is set to run weekly so I manually triggered it with
darc trigger-subscriptions --ids 2a4e5111-6978-401f-68a5-08dba3b24dbe
The subscription id is listed in the description for flow prs which makes it easy to trigger again. If I need to look up a subscription I typically use darc get-subscriptions with various args

[mangod9]

sounds good. Hoping it makes progress with latest.

[mangod9]

Appears to be still failing. Looking at the latest dump the libclrjit version changed from 9.0.0-preview.4.24223.11 to 9.0.0-preview.4.24225.8.

[AndyAyersMS]

I believe there are still issues being sorted to get a new 9P4 build out (partially because of this jit issue, which is fixed in that work), so maybe we're lagging behind in integrating runtime bits? @mmitche any ETA on a newer 9P4?

[mangod9]

Looks like the only failure is a known failure in System.Security.Cryptography.X509Certificates.Tests.ChainTests. Perhaps good to merge?

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/installer

• Subscription: 2a4e5111-6978-401f-68a5-08dba3b24dbe
• Build: 20240503.16
• Date Produced: May 3, 2024 7:05:39 PM UTC
• Commit: fa261b952d702c6bd604728fcbdb58ac071a22b1
• Branch: refs/heads/main

• Updates:
  • Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.4.24215.2 to 9.0.100-preview.5.24253.16

[lewing]

./RunTests.sh: line 94: 79 Segmentation fault (core dumped) dotnet exec xunit.console.dll Wasm.Build.Tests.dll -xml $XHARNESS_OUT/testResults.xml $HELIX_XUNIT_ARGS -nocolor -verbose -notrait category=IgnoreForCI -notrait category=failing $XUnitTraitArg $RSP_FILE

I'm merging main again but that is a non wasm runtime/xunit bug @jeffschwMSFT

[jeffschwMSFT]

@mangod9 can you take a look? thanks

[mangod9]

Hi @lewing, could you please point me to the link for the dump?

[lewing]

I think the core on https://dev.azure.com/dnceng-public/public/_build/results?buildId=664184&view=ms.vss-test-web.build-test-results-tab&runId=16469844&resultId=100001&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab is the right thing

[mangod9]

Thanks. Here is the stack of the failure. Perhaps related to #101695 -- @dotnet/jit-contrib ?

00 libclrjit!Compiler::optCompactLoop
01 libclrjit!Compiler::optFindLoops
02 libclrjit!Compiler::optFindLoopsPhase
03 libclrjit!jitNativeCode
04 libclrjit!CILJit::compileMethod
05 libcoreclr!invokeCompileMethodHelper
06 libcoreclr!invokeCompileMethod
07 libcoreclr!UnsafeJitFunction
08 libcoreclr!MethodDesc::JitCompileCodeLocked
09 libcoreclr!MethodDesc::JitCompileCodeLockedEventWrapper
0a libcoreclr!MethodDesc::JitCompileCode
0b libcoreclr!MethodDesc::PrepareILBasedCode
0c libcoreclr!TieredCompilationManager::CompileCodeVersion
0d libcoreclr!TieredCompilationManager::DoBackgroundWork
0e libcoreclr!TieredCompilationManager::BackgroundWorkerStart
0f libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper1
10 libcoreclr!ZL31ManagedThreadBase_DispatchOuterP22ManagedThreadCallState
11 libcoreclr!ManagedThreadBase::KickOff
12 libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper0
13 libcoreclr!CorUnix::CPalThread::ThreadEntry

[AndyAyersMS]

Yeah very likely the bug we just fixed. Can we update the 9P5 bits?

[mangod9]

The change seems to be picking up 9.0.100-preview.5.24229.2 but guessing we need something later than that?

[AndyAyersMS]

I think so. The fix is here #101714 so you likely need something stamped 24230 or maybe even one day later (goes up by 50 each month, right? so maybe 24250+).

[mangod9]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

[lewing]

I triggered new flow and merged main

[lewing]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

The darc subscription is set to run weekly so I manually triggered it with
darc trigger-subscriptions --ids 2a4e5111-6978-401f-68a5-08dba3b24dbe
The subscription id is listed in the description for flow prs which makes it easy to trigger again. If I need to look up a subscription I typically use darc get-subscriptions with various args

[mangod9]

sounds good. Hoping it makes progress with latest.

[mangod9]

Appears to be still failing. Looking at the latest dump the libclrjit version changed from 9.0.0-preview.4.24223.11 to 9.0.0-preview.4.24225.8.

[AndyAyersMS]

I believe there are still issues being sorted to get a new 9P4 build out (partially because of this jit issue, which is fixed in that work), so maybe we're lagging behind in integrating runtime bits? @mmitche any ETA on a newer 9P4?

[mangod9]

Looks like the only failure is a known failure in System.Security.Cryptography.X509Certificates.Tests.ChainTests. Perhaps good to merge?

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/installer

• Subscription: 2a4e5111-6978-401f-68a5-08dba3b24dbe
• Build: 20240503.16
• Date Produced: May 3, 2024 7:05:39 PM UTC
• Commit: fa261b952d702c6bd604728fcbdb58ac071a22b1
• Branch: refs/heads/main

• Updates:
  • Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.4.24215.2 to 9.0.100-preview.5.24253.16

[lewing]

./RunTests.sh: line 94: 79 Segmentation fault (core dumped) dotnet exec xunit.console.dll Wasm.Build.Tests.dll -xml $XHARNESS_OUT/testResults.xml $HELIX_XUNIT_ARGS -nocolor -verbose -notrait category=IgnoreForCI -notrait category=failing $XUnitTraitArg $RSP_FILE

I'm merging main again but that is a non wasm runtime/xunit bug @jeffschwMSFT

[jeffschwMSFT]

@mangod9 can you take a look? thanks

[mangod9]

Hi @lewing, could you please point me to the link for the dump?

[lewing]

I think the core on https://dev.azure.com/dnceng-public/public/_build/results?buildId=664184&view=ms.vss-test-web.build-test-results-tab&runId=16469844&resultId=100001&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab is the right thing

[mangod9]

Thanks. Here is the stack of the failure. Perhaps related to #101695 -- @dotnet/jit-contrib ?

00 libclrjit!Compiler::optCompactLoop
01 libclrjit!Compiler::optFindLoops
02 libclrjit!Compiler::optFindLoopsPhase
03 libclrjit!jitNativeCode
04 libclrjit!CILJit::compileMethod
05 libcoreclr!invokeCompileMethodHelper
06 libcoreclr!invokeCompileMethod
07 libcoreclr!UnsafeJitFunction
08 libcoreclr!MethodDesc::JitCompileCodeLocked
09 libcoreclr!MethodDesc::JitCompileCodeLockedEventWrapper
0a libcoreclr!MethodDesc::JitCompileCode
0b libcoreclr!MethodDesc::PrepareILBasedCode
0c libcoreclr!TieredCompilationManager::CompileCodeVersion
0d libcoreclr!TieredCompilationManager::DoBackgroundWork
0e libcoreclr!TieredCompilationManager::BackgroundWorkerStart
0f libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper1
10 libcoreclr!ZL31ManagedThreadBase_DispatchOuterP22ManagedThreadCallState
11 libcoreclr!ManagedThreadBase::KickOff
12 libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper0
13 libcoreclr!CorUnix::CPalThread::ThreadEntry

[AndyAyersMS]

Yeah very likely the bug we just fixed. Can we update the 9P5 bits?

[mangod9]

The change seems to be picking up 9.0.100-preview.5.24229.2 but guessing we need something later than that?

[AndyAyersMS]

I think so. The fix is here #101714 so you likely need something stamped 24230 or maybe even one day later (goes up by 50 each month, right? so maybe 24250+).

[mangod9]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

[lewing]

I triggered new flow and merged main

[lewing]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

The darc subscription is set to run weekly so I manually triggered it with
darc trigger-subscriptions --ids 2a4e5111-6978-401f-68a5-08dba3b24dbe
The subscription id is listed in the description for flow prs which makes it easy to trigger again. If I need to look up a subscription I typically use darc get-subscriptions with various args

[mangod9]

sounds good. Hoping it makes progress with latest.

[mangod9]

Appears to be still failing. Looking at the latest dump the libclrjit version changed from 9.0.0-preview.4.24223.11 to 9.0.0-preview.4.24225.8.

[AndyAyersMS]

I believe there are still issues being sorted to get a new 9P4 build out (partially because of this jit issue, which is fixed in that work), so maybe we're lagging behind in integrating runtime bits? @mmitche any ETA on a newer 9P4?

[mangod9]

Looks like the only failure is a known failure in System.Security.Cryptography.X509Certificates.Tests.ChainTests. Perhaps good to merge?

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/installer

• Subscription: 2a4e5111-6978-401f-68a5-08dba3b24dbe
• Build: 20240503.16
• Date Produced: May 3, 2024 7:05:39 PM UTC
• Commit: fa261b952d702c6bd604728fcbdb58ac071a22b1
• Branch: refs/heads/main

• Updates:
  • Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.4.24215.2 to 9.0.100-preview.5.24253.16

[lewing]

./RunTests.sh: line 94: 79 Segmentation fault (core dumped) dotnet exec xunit.console.dll Wasm.Build.Tests.dll -xml $XHARNESS_OUT/testResults.xml $HELIX_XUNIT_ARGS -nocolor -verbose -notrait category=IgnoreForCI -notrait category=failing $XUnitTraitArg $RSP_FILE

I'm merging main again but that is a non wasm runtime/xunit bug @jeffschwMSFT

[jeffschwMSFT]

@mangod9 can you take a look? thanks

[mangod9]

Hi @lewing, could you please point me to the link for the dump?

[lewing]

I think the core on https://dev.azure.com/dnceng-public/public/_build/results?buildId=664184&view=ms.vss-test-web.build-test-results-tab&runId=16469844&resultId=100001&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab is the right thing

[mangod9]

Thanks. Here is the stack of the failure. Perhaps related to #101695 -- @dotnet/jit-contrib ?

00 libclrjit!Compiler::optCompactLoop
01 libclrjit!Compiler::optFindLoops
02 libclrjit!Compiler::optFindLoopsPhase
03 libclrjit!jitNativeCode
04 libclrjit!CILJit::compileMethod
05 libcoreclr!invokeCompileMethodHelper
06 libcoreclr!invokeCompileMethod
07 libcoreclr!UnsafeJitFunction
08 libcoreclr!MethodDesc::JitCompileCodeLocked
09 libcoreclr!MethodDesc::JitCompileCodeLockedEventWrapper
0a libcoreclr!MethodDesc::JitCompileCode
0b libcoreclr!MethodDesc::PrepareILBasedCode
0c libcoreclr!TieredCompilationManager::CompileCodeVersion
0d libcoreclr!TieredCompilationManager::DoBackgroundWork
0e libcoreclr!TieredCompilationManager::BackgroundWorkerStart
0f libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper1
10 libcoreclr!ZL31ManagedThreadBase_DispatchOuterP22ManagedThreadCallState
11 libcoreclr!ManagedThreadBase::KickOff
12 libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper0
13 libcoreclr!CorUnix::CPalThread::ThreadEntry

[AndyAyersMS]

Yeah very likely the bug we just fixed. Can we update the 9P5 bits?

[mangod9]

The change seems to be picking up 9.0.100-preview.5.24229.2 but guessing we need something later than that?

[AndyAyersMS]

I think so. The fix is here #101714 so you likely need something stamped 24230 or maybe even one day later (goes up by 50 each month, right? so maybe 24250+).

[mangod9]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

[lewing]

I triggered new flow and merged main

[lewing]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

The darc subscription is set to run weekly so I manually triggered it with
darc trigger-subscriptions --ids 2a4e5111-6978-401f-68a5-08dba3b24dbe
The subscription id is listed in the description for flow prs which makes it easy to trigger again. If I need to look up a subscription I typically use darc get-subscriptions with various args

[mangod9]

sounds good. Hoping it makes progress with latest.

[mangod9]

Appears to be still failing. Looking at the latest dump the libclrjit version changed from 9.0.0-preview.4.24223.11 to 9.0.0-preview.4.24225.8.

[AndyAyersMS]

I believe there are still issues being sorted to get a new 9P4 build out (partially because of this jit issue, which is fixed in that work), so maybe we're lagging behind in integrating runtime bits? @mmitche any ETA on a newer 9P4?

[mangod9]

Looks like the only failure is a known failure in System.Security.Cryptography.X509Certificates.Tests.ChainTests. Perhaps good to merge?

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/installer

• Subscription: 2a4e5111-6978-401f-68a5-08dba3b24dbe
• Build: 20240503.16
• Date Produced: May 3, 2024 7:05:39 PM UTC
• Commit: fa261b952d702c6bd604728fcbdb58ac071a22b1
• Branch: refs/heads/main

• Updates:
  • Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.4.24215.2 to 9.0.100-preview.5.24253.16

[lewing]

./RunTests.sh: line 94: 79 Segmentation fault (core dumped) dotnet exec xunit.console.dll Wasm.Build.Tests.dll -xml $XHARNESS_OUT/testResults.xml $HELIX_XUNIT_ARGS -nocolor -verbose -notrait category=IgnoreForCI -notrait category=failing $XUnitTraitArg $RSP_FILE

I'm merging main again but that is a non wasm runtime/xunit bug @jeffschwMSFT

[jeffschwMSFT]

@mangod9 can you take a look? thanks

[mangod9]

Hi @lewing, could you please point me to the link for the dump?

[lewing]

I think the core on https://dev.azure.com/dnceng-public/public/_build/results?buildId=664184&view=ms.vss-test-web.build-test-results-tab&runId=16469844&resultId=100001&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab is the right thing

[mangod9]

Thanks. Here is the stack of the failure. Perhaps related to #101695 -- @dotnet/jit-contrib ?

00 libclrjit!Compiler::optCompactLoop
01 libclrjit!Compiler::optFindLoops
02 libclrjit!Compiler::optFindLoopsPhase
03 libclrjit!jitNativeCode
04 libclrjit!CILJit::compileMethod
05 libcoreclr!invokeCompileMethodHelper
06 libcoreclr!invokeCompileMethod
07 libcoreclr!UnsafeJitFunction
08 libcoreclr!MethodDesc::JitCompileCodeLocked
09 libcoreclr!MethodDesc::JitCompileCodeLockedEventWrapper
0a libcoreclr!MethodDesc::JitCompileCode
0b libcoreclr!MethodDesc::PrepareILBasedCode
0c libcoreclr!TieredCompilationManager::CompileCodeVersion
0d libcoreclr!TieredCompilationManager::DoBackgroundWork
0e libcoreclr!TieredCompilationManager::BackgroundWorkerStart
0f libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper1
10 libcoreclr!ZL31ManagedThreadBase_DispatchOuterP22ManagedThreadCallState
11 libcoreclr!ManagedThreadBase::KickOff
12 libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper0
13 libcoreclr!CorUnix::CPalThread::ThreadEntry

[AndyAyersMS]

Yeah very likely the bug we just fixed. Can we update the 9P5 bits?

[mangod9]

The change seems to be picking up 9.0.100-preview.5.24229.2 but guessing we need something later than that?

[AndyAyersMS]

I think so. The fix is here #101714 so you likely need something stamped 24230 or maybe even one day later (goes up by 50 each month, right? so maybe 24250+).

[mangod9]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

[lewing]

I triggered new flow and merged main

[lewing]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

The darc subscription is set to run weekly so I manually triggered it with
darc trigger-subscriptions --ids 2a4e5111-6978-401f-68a5-08dba3b24dbe
The subscription id is listed in the description for flow prs which makes it easy to trigger again. If I need to look up a subscription I typically use darc get-subscriptions with various args

[mangod9]

sounds good. Hoping it makes progress with latest.

[mangod9]

Appears to be still failing. Looking at the latest dump the libclrjit version changed from 9.0.0-preview.4.24223.11 to 9.0.0-preview.4.24225.8.

[AndyAyersMS]

I believe there are still issues being sorted to get a new 9P4 build out (partially because of this jit issue, which is fixed in that work), so maybe we're lagging behind in integrating runtime bits? @mmitche any ETA on a newer 9P4?

[mangod9]

Looks like the only failure is a known failure in System.Security.Cryptography.X509Certificates.Tests.ChainTests. Perhaps good to merge?

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/installer

• Subscription: 2a4e5111-6978-401f-68a5-08dba3b24dbe
• Build: 20240503.16
• Date Produced: May 3, 2024 7:05:39 PM UTC
• Commit: fa261b952d702c6bd604728fcbdb58ac071a22b1
• Branch: refs/heads/main

• Updates:
  • Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.4.24215.2 to 9.0.100-preview.5.24253.16

[lewing]

./RunTests.sh: line 94: 79 Segmentation fault (core dumped) dotnet exec xunit.console.dll Wasm.Build.Tests.dll -xml $XHARNESS_OUT/testResults.xml $HELIX_XUNIT_ARGS -nocolor -verbose -notrait category=IgnoreForCI -notrait category=failing $XUnitTraitArg $RSP_FILE

I'm merging main again but that is a non wasm runtime/xunit bug @jeffschwMSFT

[jeffschwMSFT]

@mangod9 can you take a look? thanks

[mangod9]

Hi @lewing, could you please point me to the link for the dump?

[lewing]

I think the core on https://dev.azure.com/dnceng-public/public/_build/results?buildId=664184&view=ms.vss-test-web.build-test-results-tab&runId=16469844&resultId=100001&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab is the right thing

[mangod9]

Thanks. Here is the stack of the failure. Perhaps related to #101695 -- @dotnet/jit-contrib ?

00 libclrjit!Compiler::optCompactLoop
01 libclrjit!Compiler::optFindLoops
02 libclrjit!Compiler::optFindLoopsPhase
03 libclrjit!jitNativeCode
04 libclrjit!CILJit::compileMethod
05 libcoreclr!invokeCompileMethodHelper
06 libcoreclr!invokeCompileMethod
07 libcoreclr!UnsafeJitFunction
08 libcoreclr!MethodDesc::JitCompileCodeLocked
09 libcoreclr!MethodDesc::JitCompileCodeLockedEventWrapper
0a libcoreclr!MethodDesc::JitCompileCode
0b libcoreclr!MethodDesc::PrepareILBasedCode
0c libcoreclr!TieredCompilationManager::CompileCodeVersion
0d libcoreclr!TieredCompilationManager::DoBackgroundWork
0e libcoreclr!TieredCompilationManager::BackgroundWorkerStart
0f libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper1
10 libcoreclr!ZL31ManagedThreadBase_DispatchOuterP22ManagedThreadCallState
11 libcoreclr!ManagedThreadBase::KickOff
12 libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper0
13 libcoreclr!CorUnix::CPalThread::ThreadEntry

[AndyAyersMS]

Yeah very likely the bug we just fixed. Can we update the 9P5 bits?

[mangod9]

The change seems to be picking up 9.0.100-preview.5.24229.2 but guessing we need something later than that?

[AndyAyersMS]

I think so. The fix is here #101714 so you likely need something stamped 24230 or maybe even one day later (goes up by 50 each month, right? so maybe 24250+).

[mangod9]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

[lewing]

I triggered new flow and merged main

[lewing]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

The darc subscription is set to run weekly so I manually triggered it with
darc trigger-subscriptions --ids 2a4e5111-6978-401f-68a5-08dba3b24dbe
The subscription id is listed in the description for flow prs which makes it easy to trigger again. If I need to look up a subscription I typically use darc get-subscriptions with various args

[mangod9]

sounds good. Hoping it makes progress with latest.

[mangod9]

Appears to be still failing. Looking at the latest dump the libclrjit version changed from 9.0.0-preview.4.24223.11 to 9.0.0-preview.4.24225.8.

[AndyAyersMS]

I believe there are still issues being sorted to get a new 9P4 build out (partially because of this jit issue, which is fixed in that work), so maybe we're lagging behind in integrating runtime bits? @mmitche any ETA on a newer 9P4?

[mangod9]

Looks like the only failure is a known failure in System.Security.Cryptography.X509Certificates.Tests.ChainTests. Perhaps good to merge?

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/installer

• Subscription: 2a4e5111-6978-401f-68a5-08dba3b24dbe
• Build: 20240503.16
• Date Produced: May 3, 2024 7:05:39 PM UTC
• Commit: fa261b952d702c6bd604728fcbdb58ac071a22b1
• Branch: refs/heads/main

• Updates:
  • Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.4.24215.2 to 9.0.100-preview.5.24253.16

[lewing]

./RunTests.sh: line 94: 79 Segmentation fault (core dumped) dotnet exec xunit.console.dll Wasm.Build.Tests.dll -xml $XHARNESS_OUT/testResults.xml $HELIX_XUNIT_ARGS -nocolor -verbose -notrait category=IgnoreForCI -notrait category=failing $XUnitTraitArg $RSP_FILE

I'm merging main again but that is a non wasm runtime/xunit bug @jeffschwMSFT

[jeffschwMSFT]

@mangod9 can you take a look? thanks

[mangod9]

Hi @lewing, could you please point me to the link for the dump?

[lewing]

I think the core on https://dev.azure.com/dnceng-public/public/_build/results?buildId=664184&view=ms.vss-test-web.build-test-results-tab&runId=16469844&resultId=100001&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab is the right thing

[mangod9]

Thanks. Here is the stack of the failure. Perhaps related to #101695 -- @dotnet/jit-contrib ?

00 libclrjit!Compiler::optCompactLoop
01 libclrjit!Compiler::optFindLoops
02 libclrjit!Compiler::optFindLoopsPhase
03 libclrjit!jitNativeCode
04 libclrjit!CILJit::compileMethod
05 libcoreclr!invokeCompileMethodHelper
06 libcoreclr!invokeCompileMethod
07 libcoreclr!UnsafeJitFunction
08 libcoreclr!MethodDesc::JitCompileCodeLocked
09 libcoreclr!MethodDesc::JitCompileCodeLockedEventWrapper
0a libcoreclr!MethodDesc::JitCompileCode
0b libcoreclr!MethodDesc::PrepareILBasedCode
0c libcoreclr!TieredCompilationManager::CompileCodeVersion
0d libcoreclr!TieredCompilationManager::DoBackgroundWork
0e libcoreclr!TieredCompilationManager::BackgroundWorkerStart
0f libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper1
10 libcoreclr!ZL31ManagedThreadBase_DispatchOuterP22ManagedThreadCallState
11 libcoreclr!ManagedThreadBase::KickOff
12 libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper0
13 libcoreclr!CorUnix::CPalThread::ThreadEntry

[AndyAyersMS]

Yeah very likely the bug we just fixed. Can we update the 9P5 bits?

[mangod9]

The change seems to be picking up 9.0.100-preview.5.24229.2 but guessing we need something later than that?

[AndyAyersMS]

I think so. The fix is here #101714 so you likely need something stamped 24230 or maybe even one day later (goes up by 50 each month, right? so maybe 24250+).

[mangod9]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

[lewing]

I triggered new flow and merged main

[lewing]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

The darc subscription is set to run weekly so I manually triggered it with
darc trigger-subscriptions --ids 2a4e5111-6978-401f-68a5-08dba3b24dbe
The subscription id is listed in the description for flow prs which makes it easy to trigger again. If I need to look up a subscription I typically use darc get-subscriptions with various args

[mangod9]

sounds good. Hoping it makes progress with latest.

[mangod9]

Appears to be still failing. Looking at the latest dump the libclrjit version changed from 9.0.0-preview.4.24223.11 to 9.0.0-preview.4.24225.8.

[AndyAyersMS]

I believe there are still issues being sorted to get a new 9P4 build out (partially because of this jit issue, which is fixed in that work), so maybe we're lagging behind in integrating runtime bits? @mmitche any ETA on a newer 9P4?

[mangod9]

Looks like the only failure is a known failure in System.Security.Cryptography.X509Certificates.Tests.ChainTests. Perhaps good to merge?

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/installer

• Subscription: 2a4e5111-6978-401f-68a5-08dba3b24dbe
• Build: 20240503.16
• Date Produced: May 3, 2024 7:05:39 PM UTC
• Commit: fa261b952d702c6bd604728fcbdb58ac071a22b1
• Branch: refs/heads/main

• Updates:
  • Microsoft.Dotnet.Sdk.Internal: from 9.0.100-preview.4.24215.2 to 9.0.100-preview.5.24253.16

[lewing]

./RunTests.sh: line 94: 79 Segmentation fault (core dumped) dotnet exec xunit.console.dll Wasm.Build.Tests.dll -xml $XHARNESS_OUT/testResults.xml $HELIX_XUNIT_ARGS -nocolor -verbose -notrait category=IgnoreForCI -notrait category=failing $XUnitTraitArg $RSP_FILE

I'm merging main again but that is a non wasm runtime/xunit bug @jeffschwMSFT

[jeffschwMSFT]

@mangod9 can you take a look? thanks

[mangod9]

Hi @lewing, could you please point me to the link for the dump?

[lewing]

I think the core on https://dev.azure.com/dnceng-public/public/_build/results?buildId=664184&view=ms.vss-test-web.build-test-results-tab&runId=16469844&resultId=100001&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab is the right thing

[mangod9]

Thanks. Here is the stack of the failure. Perhaps related to #101695 -- @dotnet/jit-contrib ?

00 libclrjit!Compiler::optCompactLoop
01 libclrjit!Compiler::optFindLoops
02 libclrjit!Compiler::optFindLoopsPhase
03 libclrjit!jitNativeCode
04 libclrjit!CILJit::compileMethod
05 libcoreclr!invokeCompileMethodHelper
06 libcoreclr!invokeCompileMethod
07 libcoreclr!UnsafeJitFunction
08 libcoreclr!MethodDesc::JitCompileCodeLocked
09 libcoreclr!MethodDesc::JitCompileCodeLockedEventWrapper
0a libcoreclr!MethodDesc::JitCompileCode
0b libcoreclr!MethodDesc::PrepareILBasedCode
0c libcoreclr!TieredCompilationManager::CompileCodeVersion
0d libcoreclr!TieredCompilationManager::DoBackgroundWork
0e libcoreclr!TieredCompilationManager::BackgroundWorkerStart
0f libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper1
10 libcoreclr!ZL31ManagedThreadBase_DispatchOuterP22ManagedThreadCallState
11 libcoreclr!ManagedThreadBase::KickOff
12 libcoreclr!TieredCompilationManager::BackgroundWorkerBootstrapper0
13 libcoreclr!CorUnix::CPalThread::ThreadEntry

[AndyAyersMS]

Yeah very likely the bug we just fixed. Can we update the 9P5 bits?

[mangod9]

The change seems to be picking up 9.0.100-preview.5.24229.2 but guessing we need something later than that?

[AndyAyersMS]

I think so. The fix is here #101714 so you likely need something stamped 24230 or maybe even one day later (goes up by 50 each month, right? so maybe 24250+).

[mangod9]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

[lewing]

I triggered new flow and merged main

[lewing]

@lewing would `dotnet-maestro' pickup a newer build automagically or does it need a hand update?

The darc subscription is set to run weekly so I manually triggered it with
darc trigger-subscriptions --ids 2a4e5111-6978-401f-68a5-08dba3b24dbe
The subscription id is listed in the description for flow prs which makes it easy to trigger again. If I need to look up a subscription I typically use darc get-subscriptions with various args

[mangod9]

sounds good. Hoping it makes progress with latest.

[mangod9]

Appears to be still failing. Looking at the latest dump the libclrjit version changed from 9.0.0-preview.4.24223.11 to 9.0.0-preview.4.24225.8.

[AndyAyersMS]

I believe there are still issues being sorted to get a new 9P4 build out (partially because of this jit issue, which is fixed in that work), so maybe we're lagging behind in integrating runtime bits? @mmitche any ETA on a newer 9P4?

[mangod9]

Looks like the only failure is a known failure in System.Security.Cryptography.X509Certificates.Tests.ChainTests. Perhaps good to merge?