Prevent AssemblyResolve Event from causing infinite recursion on mscorlib resource lookup#573
Merged
zacharycmontoya merged 9 commits intoDec 2, 2019
Conversation
zacharycmontoya
commented
Nov 27, 2019
zacharycmontoya
commented
Nov 27, 2019
| // to enter the AssemblyResolve event when searching for resources | ||
| // in its satellite assemblies. Exit early so we don't cause | ||
| // infinite recursion. | ||
| if (string.Equals(assemblyName, "mscorlib.resources", StringComparison.OrdinalIgnoreCase)) |
Contributor
Author
There was a problem hiding this comment.
This is the fix for .NET Framework. Since the fix is commented out, we will see a failure in CI, at which point I will re-enable the fix.
Member
There was a problem hiding this comment.
Would it be safer to check for any resource assembly (*.resources)?
Contributor
Author
There was a problem hiding this comment.
No other resource assembly will cause this recursion issue so I think it's helpful to single out this particular issue. We could add another check for resources assemblies in general as a small optimization if you'd like, but it wouldn't necessarily provide any more safety.
Member
There was a problem hiding this comment.
Should we not limit our checks to only our dependencies?
Member
There was a problem hiding this comment.
In other words, wouldn't this be resolved by short-circuiting when the assembly name is not one of those WE need?
…IntegrationTests.SmokeTests to actually run them in CI
…rofiler.IntegrationTests.SmokeTests to actually run them in CI" This reverts commit bea87c7.
…rash to linux build.
…nger timing out in the Windows CI.
bobuva
approved these changes
Dec 2, 2019
lucaspimentel
approved these changes
Dec 2, 2019
MikeGoldsmith
pushed a commit
to lightstep/ls-trace-dotnet
that referenced
this pull request
Mar 20, 2020
…rlib resource lookup (DataDog#573) Modifies the AssemblyResolve event handler in the Datadog.Trace.ClrProfiler.Managed.Loader assembly to eagerly exit if the requested assembly is `mscorlib.resources` or `System.Private.CoreLib.resources` on .NET Framework and .NET Core, respectively. This fixes a known issue where on a non-US locale, a lookup of an `mscorlib` resource invokes the AssemblyResolve event and our event handler causes infinite recursion and the .NET application to crash. This occurred because, in processing the event, the event handler would make a method call to `File.Exists`, which triggers yet another AssemblyResolve event for `mscorlib` and the cycle continues. Even though this has only been demonstrated to occur on .NET Framework and should not occur on .NET Core 2.0+ (see https://github.com/dotnet/coreclr/issues/12668), proactively guard against AssemblyResolve events for `System.Private.CoreLib.resources` as well.
macrogreg
pushed a commit
that referenced
this pull request
Aug 20, 2021
…rlib resource lookup (#573) Modifies the AssemblyResolve event handler in the Datadog.Trace.ClrProfiler.Managed.Loader assembly to eagerly exit if the requested assembly is `mscorlib.resources` or `System.Private.CoreLib.resources` on .NET Framework and .NET Core, respectively. This fixes a known issue where on a non-US locale, a lookup of an `mscorlib` resource invokes the AssemblyResolve event and our event handler causes infinite recursion and the .NET application to crash. This occurred because, in processing the event, the event handler would make a method call to `File.Exists`, which triggers yet another AssemblyResolve event for `mscorlib` and the cycle continues. Even though this has only been demonstrated to occur on .NET Framework and should not occur on .NET Core 2.0+ (see https://github.com/dotnet/coreclr/issues/12668), proactively guard against AssemblyResolve events for `System.Private.CoreLib.resources` as well.
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
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.
Changes proposed in this pull request:
Modifies the AssemblyResolve event handler in the Datadog.Trace.ClrProfiler.Managed.Loader assembly to eagerly exit if the requested assembly is
mscorlib.resourcesorSystem.Private.CoreLib.resourceson .NET Framework and .NET Core, respectively.This fixes a known issue where on a non-US locale, a lookup of an
mscorlibresource invokes the AssemblyResolve event and our event handler causes infinite recursion and the .NET application to crash. This occurred because, in processing the event, the event handler would make a method call toFile.Exists, which triggers yet another AssemblyResolve event formscorliband the cycle continues. Even though this has only been demonstrated to occur on .NET Framework and should not occur on .NET Core 2.0+ (see https://github.com/dotnet/coreclr/issues/12668), proactively guard against AssemblyResolve events forSystem.Private.CoreLib.resourcesas well.@DataDog/apm-dotnet