-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[manual] Merge release/7.0-staging into release/7.0 #93582
Merged
carlossanlop
merged 20 commits into
dotnet:release/7.0
from
carlossanlop:release/7.0-staging
Oct 17, 2023
Merged
[manual] Merge release/7.0-staging into release/7.0 #93582
carlossanlop
merged 20 commits into
dotnet:release/7.0
from
carlossanlop:release/7.0-staging
Oct 17, 2023
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…dotnet#92033) This adds a check for the framework's .deps.json instead of just the existence of the directory. To avoid extra file checks in the normal/happy path (where all framework version folder are valid), when resolving, it only does the check after resolving the best version match. And if that version directory isn't valid, it tries resolving again without it. Backport of dotnet#90035
* Fix JsonDocument thread safety. Co-authored-by: stoub@microsoft.com * Update ServicingVersion --------- Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
…/7.0-to-release/7.0-staging [automated] Merge branch 'release/7.0' => 'release/7.0-staging'
…04.1 (dotnet#92991) Microsoft.NET.Workload.Emscripten.net6.Manifest-7.0.100 , Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100 From Version 7.0.12 -> To Version 7.0.13 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…#93006) Backport of dotnet#75088 to release/7.0-staging Fixes dotnet#81211 ## Customer Impact Customers targeting Apple platforms using LLVM AOT codegen (the default) in highly concurrent settings (such as firing off multiple simultaneous async HTTP requests) may experience unexpected behavior such as InvalidCastExceptions, NullReferenceExceptions or crashes. ## Testing Manual testing ## Risk Low. This code has been running on .NET 8 `main` for over a year in CI, as well as on some other non-mobile platforms --- * [Mono] Race in init_method when using LLVM AOT. When using LLVM AOT codegen, init_method updates two GOT slots. These slots are initialized as part of init_method, but there is a race between initialization of the two slots. Current implementation can have two threads running init_method for the same method, but as soon as: [got_slots [pindex]] = addr store is visible, it will trigger other threads to return back from init_method, but since that could happen before the corresponding LLVM AOT const slot is set, second thread will return to method calling init_method, load the LLVM aot const, and crash when trying to use it (since its still NULL). This crash is very rare but have been identified on x86/x64 CPU's, when one thread is either preempted between updating regular GOT slot and LLVM GOT slot or store into LLVM GOT slot gets delayed in store buffer. I have also been able to emulate the scenario in debugger, triggering the issue and crashing in the method loading from LLVM aot const slot. Fix change order of updates and make sure the update of LLVM aot const slot happens before memory_barrier, since: got [got_slots [pindex]] = addr; have release semantics in relation to addr and update of LLVM aot const slot. Fix also add acquire/release semantics for ji->type in init_method since it is used to guard if a thread ignores a patch or not and it should not be re-ordered with previous stores, since it can cause similar race conditions with updated slots. * Move register_jump_target_got_slot above mono_memory_barrier. * revert unintentional branding change --------- Co-authored-by: vseanreesermsft <78103370+vseanreesermsft@users.noreply.github.com> Co-authored-by: lateralusX <lateralusx.github@gmail.com> Co-authored-by: Aleksey Kliger <alklig@microsoft.com>
… using an array of structs of types that use old-style managed marshalers (dotnet#93148) Co-authored-by: Jeremy Koritzinsky <jekoritz@microsoft.com>
- Added two config options, one that configures the worker and wait thread timeouts, and another that enables keeping some number of worker threads alive after they are created - This enables services that take periodic traffic to keep some worker threads around for better latency, while allowing extra threads to time out as appropriate for the service
When the new stub heaps were implemented, the chunk size needed to be limited so that all precodes for a chunk fit into a single memory page. That was done in `MethodDescChunk::CreateChunk`. But it was discovered now that there is another place where it needs to be limited, the `MethodTableBuilder::AllocAndInitMethodDescChunk`. The JIT\opt\ObjectStackAllocation\ObjectStackAllocationTests started to fail in the outerloop due to too long chunk. The failure happens in crossgen2 as it is using a separate build of runtime in release and only that uncovers the problem. And only when DOTNET_TieredCompilation=0 and DOTNET_ProfApi_RejitOnAttach=0. This change fixes the problem. With this change applied to the dotnet runtime version used by the crossgen2 and patching it in place in the .dotnet/shared/.... directory, the issue doesn't occur. Close dotnet#81103 Co-authored-by: Jan Vorlicek <janvorli@microsoft.com>
…/7.0-to-release/7.0-staging [automated] Merge branch 'release/7.0' => 'release/7.0-staging'
…30905.3 (dotnet#93392) Microsoft.DotNet.XHarness.CLI , Microsoft.DotNet.XHarness.TestRunners.Common , Microsoft.DotNet.XHarness.TestRunners.Xunit From Version 7.0.0-prerelease.23407.3 -> To Version 7.0.0-prerelease.23455.3 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
…kernel. (dotnet#93505) Co-authored-by: Tom Deseyn <tom.deseyn@gmail.com>
…cu dotnet/emsdk (dotnet#93390) * Update dependencies from https://github.com/dotnet/arcade build 20231011.9 Microsoft.DotNet.ApiCompat , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.GenAPI , Microsoft.DotNet.GenFacades , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.XUnitExtensions From Version 7.0.0-beta.23408.3 -> To Version 7.0.0-beta.23511.9 * Update dependencies from https://github.com/dotnet/icu build 20231012.1 Microsoft.NETCore.Runtime.ICU.Transport From Version 7.0.0-rtm.23409.2 -> To Version 7.0.0-rtm.23512.1 * Update dependencies from https://github.com/dotnet/emsdk build 20231012.1 Microsoft.NET.Workload.Emscripten.net6.Manifest-7.0.100 , Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100 From Version 7.0.13 -> To Version 7.0.13 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>
…efault path (dotnet#92955) * Fixing https://github.com/dotnet/aspnetcore/issues/51093 * Addressing comments * Addressing comments * Addressing comments
…ocess. (dotnet#85649) (dotnet#93572) * ProcessTests: allow WorkingSet to be zero just after launching the process. The WorkingSet tests fail on Fedora 38+ because a zero working set value is observed just after the process start. Co-authored-by: Tom Deseyn <tom.deseyn@gmail.com>
carlossanlop
requested review from
lewing,
steveisok,
ViktorHofer,
ericstj,
hoyosjs and
a team
October 17, 2023 00:07
carlossanlop
requested review from
radical,
thaystg,
vargaz,
lambdageek,
SamMonoRT and
marek-safar
as code owners
October 17, 2023 00:07
This was referenced Oct 17, 2023
ericstj
approved these changes
Oct 17, 2023
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merge commit.