Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

Conversation

vseanreesermsft
Copy link

No description provided.

carlossanlop and others added 19 commits October 17, 2022 19:42
Submiting this directly to the internal branch for speed.
I added a comment to indicate that it should never be removed, only commented, since it's a special kind of OOB package.
Fixes dotnet/runtime#76338
The latest PRs have been failing to find Debian.9.Amd64 (Unknown QueueId error).
The fist commit removes all instances of the Debian.9.Amd64 queue.
The second commit appends Debian.10.Amd64 at the end in the two lines where it was not added yet.
The third commit fixes the location of the wrongly placed new queues.
Updated windows build image override to Windows.10.vs2019.amd64
…otnet-coreclr build 20221109.2

Microsoft.NET.Sdk.IL , Microsoft.NETCore.ILAsm , Microsoft.NETCore.Runtime.CoreCLR
 From Version 3.1.32-servicing.22552.2 -> To Version 3.1.32-servicing.22559.2
…ng/internal/dotnet-coreclr

This pull request updates the following dependencies

[marker]: <> (Begin:e602b4c3-5c4b-44ff-d44b-08d76e1d3434)
## From https://dev.azure.com/dnceng/internal/_git/dotnet-coreclr
- **Subscription**: e602b4c3-5c4b-44ff-d44b-08d76e1d3434
- **Build**: 20221109.2
- **Date Produced**: November 9, 2022 8:01:13 PM UTC
- **Commit**: c17d273aa03d4b9d14c92248a91f0d0faa881b98
- **Branch**: refs/heads/internal/release/3.1

[DependencyUpdate]: <> (Begin)

- **Updates**:
  - **Microsoft.NET.Sdk.IL**: [from 3.1.32-servicing.22552.2 to 3.1.32-servicing.22559.2][1]
  - **Microsoft.NETCore.ILAsm**: [from 3.1.32-servicing.22552.2 to 3.1.32-servicing.22559.2][1]
  - **Microsoft.NETCore.Runtime.CoreCLR**: [from 3.1.32-servicing.22552.2 to 3.1.32-servicing.22559.2][1]

[1]: https://dev.azure.com/dnceng/internal/_git/dotnet-coreclr/branches?baseVersion=GCce605ef&targetVersion=GCc17d273&_a=files

[DependencyUpdate]: <> (End)

[marker]: <> (End:e602b4c3-5c4b-44ff-d44b-08d76e1d3434)
…otnet-coreclr build 20221129.2

Microsoft.NET.Sdk.IL , Microsoft.NETCore.ILAsm , Microsoft.NETCore.Runtime.CoreCLR
 From Version 3.1.32-servicing.22559.2 -> To Version 3.1.33-servicing.22579.2
…ng/internal/dotnet-coreclr

This pull request updates the following dependencies

[marker]: <> (Begin:e602b4c3-5c4b-44ff-d44b-08d76e1d3434)
## From https://dev.azure.com/dnceng/internal/_git/dotnet-coreclr
- **Subscription**: e602b4c3-5c4b-44ff-d44b-08d76e1d3434
- **Build**: 20221129.2
- **Date Produced**: November 30, 2022 12:37:32 AM UTC
- **Commit**: 48fb77088b34c479b6fef71e649900d9cbd42b7c
- **Branch**: refs/heads/internal/release/3.1

[DependencyUpdate]: <> (Begin)

- **Updates**:
  - **Microsoft.NET.Sdk.IL**: [from 3.1.32-servicing.22559.2 to 3.1.33-servicing.22579.2][1]
  - **Microsoft.NETCore.ILAsm**: [from 3.1.32-servicing.22559.2 to 3.1.33-servicing.22579.2][1]
  - **Microsoft.NETCore.Runtime.CoreCLR**: [from 3.1.32-servicing.22559.2 to 3.1.33-servicing.22579.2][1]

[1]: https://dev.azure.com/dnceng/internal/_git/dotnet-coreclr/branches?baseVersion=GCc17d273&targetVersion=GC48fb770&_a=files

[DependencyUpdate]: <> (End)

[marker]: <> (End:e602b4c3-5c4b-44ff-d44b-08d76e1d3434)
…8/7.0-style checks for recursive collections to avoid StackOverflow.

# DataContractSerializer - Fix StackOverflow when working with some recursive collections

Bring back more thorough 4.8/7.0-style checks for recursive collections to avoid StackOverflow.

## Description

ASP.Net Core is hitting a situation where an empty JObject from JSON.Net  is being fed into XsdDataContractExporter and results in an uncatchable StackOverflowException. The reason is because JObject (actually, JToken) is a recursive object/collection which fails the recursive collection check in .Net Core up until 7.0. Before 7.0, the DCS classes in Core were based on a strange Silverlight port of DCS. In 7.0, the DCS space has been re-aligned with .Net 4.8 - and both 7.0 and NetFx have a more complete set of checks for recursive objects.

This PR does not come anywhere close to re-aligning the 3.1/5/6 DCS implementations with 4.8/7. But it does bring the more robust recursive object check back.

The result of this change will still be an exception on JObject, but it will be one noting that it is a recursive object and can't be serialized with DCS - most importantly, the new exception is catchable and will not crash the host process.

Fixes MSRC 75016

## Customer Impact

While from a DCS perspective, it would be easy to say that if a user passes bad input into the API, bad things could happen... so don't do that. The fix here still results in "failure," albeit a recoverable one. However, the scenario that raises the issue here is one that is apparently unavoidable according to the architecture of ASP.Net Core formatter execution. Without the fix, empty HTTP responses as JObjects result in a process crash.

## Regression?

- [ ] Yes
- [x] No

Not in Core anyway. DCS has always been like this in Core. It does not repro on .Net 4.8 however, so it could be considered a regression compared to NetFx.

## Risk

- [ ] High
- [ ] Medium
- [x] Low

The extended check is ported directly from the code that handled this in .Net 4.8 and was recently ported back to .Net 7.0.

## Verification

- [x] Manual (required)
- [ ] Automated

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [x] N/A

----

## When servicing release/2.1

- [ ] Make necessary changes in eng/PatchConfig.props
@wtgodbe wtgodbe closed this Jan 10, 2023
@vseanreesermsft vseanreesermsft deleted the internal-merge-3.1-2023-01-10-1106 branch January 10, 2023 20:49
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants