Bump mono to get debugging fix when using the interpreter. #15507
Conversation
This file contains hidden or 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
New commits in mono/mono: * mono/mono@2a19f878dab Backport dotnet/runtime#71436 * mono/mono@6051b710727 Bump nuget.exe to v6.2.1 * mono/mono@f354099a6b6 Set app context to null on thread detach * mono/mono@6c7e72dd8e0 [mono] Fix a crash during stack trace construction if a this object is null. Diff: https://github.com/mono/mono/compare/dffa5ab92245f2419238a35b7c2052e9a24036b4..2a19f878dab8d2e62123e0bf29453de553f5402a
Member
Author
|
/sudo backport d17-2 |
Collaborator
|
Backport Job to branch d17-2 Created! The magic is happening here |
Collaborator
|
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6420337 for more details. |
rolfbjarne
added a commit
that referenced
this pull request
Jul 15, 2022
…15451) There's a bug in the Mono runtime where the interpreter does not disable optimizations when the debugger is attached, which leads to the interpreter optimizing code and the debugger ending up rather confused. The bug is fixed in the Mono runtime (dotnet/runtime#71436), but there's no immediate way for the runtime to release this fix, so here we're implementing a workaround that disables interpreter optimizations if the debugging is enabled. It's somewhat clunky because the Mono external API wasn't designed for this, so we have to abuse the API a bit to accomplish the effect we want. This is somewhat risky (since we're changing the startup path in a pretty big way), but there's an escape hatch via an environment variable, and also the workaround will not be in effect for release builds. While the runtime issue exists in legacy mono/mono as well, we'll fix the Mono runtime for legacy, because we don't have to wait to consume legacy mono (#15507). This means that the workaround is for .NET scenarios only. Co-authored-by: Manuel de la Pena <[email protected]> Co-authored-by: Rolf Bjarne Kvinge <[email protected]>
rolfbjarne
added a commit
to rolfbjarne/macios
that referenced
this pull request
Jul 15, 2022
…otnet#15451) There's a bug in the Mono runtime where the interpreter does not disable optimizations when the debugger is attached, which leads to the interpreter optimizing code and the debugger ending up rather confused. The bug is fixed in the Mono runtime (dotnet/runtime#71436), but there's no immediate way for the runtime to release this fix, so here we're implementing a workaround that disables interpreter optimizations if the debugging is enabled. It's somewhat clunky because the Mono external API wasn't designed for this, so we have to abuse the API a bit to accomplish the effect we want. This is somewhat risky (since we're changing the startup path in a pretty big way), but there's an escape hatch via an environment variable, and also the workaround will not be in effect for release builds. While the runtime issue exists in legacy mono/mono as well, we'll fix the Mono runtime for legacy, because we don't have to wait to consume legacy mono (dotnet#15507). This means that the workaround is for .NET scenarios only. Co-authored-by: Manuel de la Pena <[email protected]> Co-authored-by: Rolf Bjarne Kvinge <[email protected]>
rolfbjarne
pushed a commit
to rolfbjarne/macios
that referenced
this pull request
Jul 15, 2022
There's a bug in the Mono runtime where the interpreter does not disable optimizations when the debugger is attached, which leads to the interpreter optimizing code and the debugger ending up rather confused. The bug is fixed in the Mono runtime (dotnet/runtime#71436), but there's no immediate way for the runtime to release this fix, so here we're implementing a workaround that disables interpreter optimizations if the debugging is enabled. It's somewhat clunky because the Mono external API wasn't designed for this, so we have to abuse the API a bit to accomplish the effect we want. This is somewhat risky (since we're changing the startup path in a pretty big way), but there's an escape hatch via an environment variable, and also the workaround will not be in effect for release builds. While the runtime issue exists in legacy mono/mono as well, we'll fix the Mono runtime for legacy, because we don't have to wait to consume legacy mono (dotnet#15507). This means that the workaround is for .NET scenarios only. This is a backport of #dotnet#15451.
rolfbjarne
pushed a commit
to rolfbjarne/macios
that referenced
this pull request
Jul 15, 2022
There's a bug in the Mono runtime where the interpreter does not disable optimizations when the debugger is attached, which leads to the interpreter optimizing code and the debugger ending up rather confused. The bug is fixed in the Mono runtime (dotnet/runtime#71436), but there's no immediate way for the runtime to release this fix, so here we're implementing a workaround that disables interpreter optimizations if the debugging is enabled. It's somewhat clunky because the Mono external API wasn't designed for this, so we have to abuse the API a bit to accomplish the effect we want. This is somewhat risky (since we're changing the startup path in a pretty big way), but there's an escape hatch via an environment variable, and also the workaround will not be in effect for release builds. While the runtime issue exists in legacy mono/mono as well, we'll fix the Mono runtime for legacy, because we don't have to wait to consume legacy mono (dotnet#15507). This means that the workaround is for .NET scenarios only. This is a backport of #dotnet#15451.
dalexsoto
approved these changes
Jul 15, 2022
mandel-macaque
approved these changes
Jul 15, 2022
Collaborator
Collaborator
✅ API diff for current PR / commitLegacy Xamarin (No breaking changes)
NET (empty diffs)
✅ API diff vs stableLegacy Xamarin (No breaking changes).NET (No breaking changes)✅ Generator diffGenerator diff is empty Pipeline on Agent |
Collaborator
❌ [PR Build] Tests on macOS M1 - Mac Big Sur (11.5) failed ❌Failed tests are:
Pipeline on Agent |
Collaborator
💻 [PR Build] Tests on macOS Mac Catalina (10.15) passed 💻✅ All tests on macOS Mac Catalina (10.15) passed. Pipeline on Agent |
dalexsoto
pushed a commit
that referenced
this pull request
Jul 18, 2022
…15510) There's a bug in the Mono runtime where the interpreter does not disable optimizations when the debugger is attached, which leads to the interpreter optimizing code and the debugger ending up rather confused. The bug is fixed in the Mono runtime (dotnet/runtime#71436), but there's no immediate way for the runtime to release this fix, so here we're implementing a workaround that disables interpreter optimizations if the debugging is enabled. It's somewhat clunky because the Mono external API wasn't designed for this, so we have to abuse the API a bit to accomplish the effect we want. This is somewhat risky (since we're changing the startup path in a pretty big way), but there's an escape hatch via an environment variable, and also the workaround will not be in effect for release builds. While the runtime issue exists in legacy mono/mono as well, we'll fix the Mono runtime for legacy, because we don't have to wait to consume legacy mono (#15507). This means that the workaround is for .NET scenarios only. This is a backport of ##15451. Co-authored-by: Thays Grazia <[email protected]>
dalexsoto
pushed a commit
that referenced
this pull request
Jul 18, 2022
…15509) There's a bug in the Mono runtime where the interpreter does not disable optimizations when the debugger is attached, which leads to the interpreter optimizing code and the debugger ending up rather confused. The bug is fixed in the Mono runtime (dotnet/runtime#71436), but there's no immediate way for the runtime to release this fix, so here we're implementing a workaround that disables interpreter optimizations if the debugging is enabled. It's somewhat clunky because the Mono external API wasn't designed for this, so we have to abuse the API a bit to accomplish the effect we want. This is somewhat risky (since we're changing the startup path in a pretty big way), but there's an escape hatch via an environment variable, and also the workaround will not be in effect for release builds. While the runtime issue exists in legacy mono/mono as well, we'll fix the Mono runtime for legacy, because we don't have to wait to consume legacy mono (#15507). This means that the workaround is for .NET scenarios only. This is a backport of ##15451. Co-authored-by: Thays Grazia <[email protected]>
Member
|
watch sim timeout -> https://github.com/xamarin/maccore/issues/648 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
New commits in mono/mono:
Diff: https://github.com/mono/mono/compare/dffa5ab92245f2419238a35b7c2052e9a24036b4..2a19f878dab8d2e62123e0bf29453de553f5402a