You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add a fourth dotnet/runtime#127957 fingerprint to ErrorHelpers.IsRuntime127957Race:
Linux/SIGABRT (exit 134) + System.BadImageFormatException + "The metadata is corrupt".
Reason for change
Follow-up to #8665. We hit a new manifestation of the same metadata-race in CI on
arm64/net9.0 — the test failed with "Unable to determine port application is listening on"
because the sample aborted at startup:
[webserver][stderr] Unhandled exception. System.BadImageFormatException: The metadata is corrupt.
at ...PhysicalFilesWatcher.GetOrAddFilePathChangeToken(String)
...
at Microsoft.Extensions.Hosting.HostBuilder.Build()
at Samples.Security.AspNetCore5.Program.Main(String[])
The existing three fingerprints (#8665) surface the race as downstream TypeLoadException / MissingMethodException / Windows FailFast symptoms. This one is the metadata reader throwing
the corruption directly. Crash-dump analysis confirms the fingerprint:
Throw originates inside the JIT/metadata reader while compiling GetOrAddFilePathChangeToken
during the first HostBuilder.Build() — earliest startup, peak instrumentation window.
Datadog native profiler/tracer threads are attached and active in the process.
Transient (passes on retry), on a nightly arm64 build — the exact profile of the issue.
Like the others, "The metadata is corrupt" is unreachable through normal product/user code, so
the gate stays narrow. The retry/metrics harness and AspNetCoreTestFixture.TryStartApp port == null path are unchanged — only the detection is extended.
Test coverage
Existing suite. Retry/fail only fires on the narrow fingerprint.
NachoEchevarria
changed the title
Handle dotnet/runtime#127957 BadImageFormatException fingerprint in integration tests
[Test] Handle dotnet/runtime#127957 BadImageFormatException fingerprint
Jun 2, 2026
Comparing candidate commit 2d4a40a in PR branch nacho/BadImageFormatException with baseline commit ffe94ca in branch master.
Found 1 performance improvements and 1 performance regressions! Performance is the same for 70 metrics, 0 unstable metrics, 61 known flaky benchmarks, 65 flaky benchmarks without significant changes.
Explanation
This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:
🟩 = significantly better candidate vs. baseline
🟥 = significantly worse candidate vs. baseline
We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.
If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.
Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.
More details about the CI and significant changes
You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.
CIs of the difference of means are often centered around 0%, because often changes are not that big:
---------------------------------(------|---^--------)-------------------------------->
-0.6% 0% 0.3% +1.2%
| | |
lower bound of the CI --' | |
sample mean (center of the CI) -------------' |
upper bound of the CI ----------------------'
As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).
For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:
----------------------------------------|---------|---(---------^---------)---------->
0% 1% 1.3% 2.2% 3.1%
| | | |
significant impact threshold --------------' | | |
lower bound of CI --------------' | |
sample mean (center of the CI) --------------------------' |
upper bound of CI ----------------------------------'
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
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.
Summary of changes
Add a fourth
dotnet/runtime#127957fingerprint toErrorHelpers.IsRuntime127957Race:Linux/SIGABRT (exit 134) +
System.BadImageFormatException+ "The metadata is corrupt".Reason for change
Follow-up to #8665. We hit a new manifestation of the same metadata-race in CI on
arm64/net9.0 — the test failed with "Unable to determine port application is listening on"
because the sample aborted at startup:
Failing build log:
https://dev.azure.com/datadoghq/a51c4863-3eb4-4c5d-878a-58b41a049e4e/_apis/build/builds/202607/logs/6762
Implementation details
The existing three fingerprints (#8665) surface the race as downstream
TypeLoadException/MissingMethodException/ Windows FailFast symptoms. This one is the metadata reader throwingthe corruption directly. Crash-dump analysis confirms the fingerprint:
BadImageFormatException, HRESULT0x8007000b(COR_E_BADIMAGEFORMAT)GetOrAddFilePathChangeTokenduring the first
HostBuilder.Build()— earliest startup, peak instrumentation window.Like the others, "The metadata is corrupt" is unreachable through normal product/user code, so
the gate stays narrow. The retry/metrics harness and
AspNetCoreTestFixture.TryStartAppport == nullpath are unchanged — only the detection is extended.Test coverage
Existing suite. Retry/fail only fires on the narrow fingerprint.
Other details
Revisit when dotnet/runtime#127957 is fixed upstream.