Infra, Ops & WorkflowSûr100100/100
Fuzzlyn Triage (.NET)
Triage Fuzzlyn CI runs.
ou envoie-le directement à ton agent.
Installer dans ton projet
$ curl -fsSL https://arboristhree.xyz/cli/install-skill.mjs -o /tmp/arboris-install-skill.mjs && node /tmp/arboris-install-skill.mjs fuzzlyn-triage__dotnet-dotnet__src-runtime-github-skills-6afa0eb6ec9b.NET
dotnet/dotnet
Contenu à copier
---
name: fuzzlyn-triage
description: Triage Fuzzlyn CI runs.
metadata:
origin: .NET
---
# Fuzzlyn triage
#### 1 — Goal
Initial investigation of Fuzzlyn found issues with assertions in CI runs.
#### 2 — Required user inputs
Ask the user for a link to a Fuzzlyn CI run if not provided.
#### 3 — Investigation steps (must be completed in order)
1. Download all the Issues artifacts for the CI run.
These artifacts are zipped files named "Issues_{platform}_Checked.zip".
For example, "Issues_windows_x64_Checked.zip".
This may take a long time, so download these in parallel.
Extract all the downloaded zip files into a single directory, and delete the .zip files once extracted.
2. Look at the reduced examples that are available.
Focus on ones that have JIT assertion failures in them, and group by the specific assertion failure.
For each assertion failure pick a single example and create a directory named based on the number part of the seed.
Create an "example.cs" file in the directory with the content of the example.
For example, if the seed is 123456789, create a directory named "123456789" and an "example.cs" file in it with the content of the example.
3. Look for the .mc files corresponding to the examples you have created.
Move the relevant .mc files under the appropriate example folders.
4. Download the Helix payload for the host you are using to run these triage steps, from the Partition0 work item.
In most cases this will be the windows-x64 job; if you are running the triage steps on a different host, use that host's payload instead.
To download the payload, obtain the Job ID from the "Send job to Helix" step in the CI run.
Download the payload for Partition0 with `runfo get-helix-payload -j <helix job ID> -w Partition0 -o <output directory>`.
This should result in the host-appropriate corerun, superpmi, and mcs tools that you should use for the next steps.
Choose the payload based on the machine running triage, not on the platform where the examples reproduced.
Now, for each example, do the following. Do NOT parallelize. Finish ALL steps for each example before you start on the next example.
1. Use superpmi to replay the .mc files for that example until you find a context that reproduces the assertion failure.
To do that, for each example, run `superpmi.exe <path to clrjit.dll> <path to .mc>`.
The clrjit.dll used should be the one that corresponds to the target that reproduced the error.
For example, if the example reproduced on linux-x64, then use clrjit_unix_x64_x64.dll.
If the assertion failure reproduces it should give you the context index before the message, e.g. "#12345".
For the next steps use the numeric portion of that index, e.g. "12345" without the "#" symbol.
2. Once you have the context index, use superpmi to replay that specific context with `superpmi.exe <path to clrjit.dll> <path to .mc> -c <context index>`.
Validate that this reproduces the assertion failure instantly.
3. Use mcs.exe next to superpmi.exe to extract that single context to a repro.mc file with `mcs.exe -copy <context index> <path to .mc> <output repro.mc>`.
Delete all the other .mc files for that example, and keep only the repro.mc file.
4. Create a jitdump file.
To do that, run `superpmi.exe <path to clrjit.dll> <path to repro.mc> -jitoption JitDump=*` and pipe the output to a jitdump.txt file in the example's directory.
5. Analyze the jitdump file and try to come up with the root cause of that assertion failure.
The JIT source code creating the jitdump is available at src/coreclr/jit/*.
Do NOT make any changes to the source code; only analyze the jitdump file and try to come up with a root cause.
Put your analysis into an analysis.md file in the example's directory.
6. Create a details.zip file that includes the repro.mc and also the jitdump.txt file.
7. Create an issue.md file that can be used to open a GitHub issue later.
In this issue.md file include the following:
- A header with the assertion failure message.
For example, if the assertion failure is "Assertion failed: x > 0", the header should be "# Assertion failed: x > 0".
- The reduced example from the .cs file.
ALWAYS keep the comment header.
- A section containing your analysis of the jitdump.
Wrap the analysis in a `<details> <summary> Analysis of jitdump </summary> ... </details>` block.
Make sure to add a note that the analysis is AI generated.
- A blurb "Attached details.zip file that includes the repro.mc and jitdump.txt files for this example."
- A "cc @dotnet/jit-contrib" at the end to make sure the JIT team sees the issue.
8. Once you have done the above steps, proceed with the next example if there are still examples left.Colle ce Markdown dans ton agent ou utilise les boutons ci-dessus pour l’écrire dans ton projet.
Ce que fait Fuzzlyn Triage (.NET)
A header with the assertion failure message.
The reduced example from the .cs file.
A section containing your analysis of the jitdump.
A blurb "Attached details.zip file that includes the repro.mc and jitdump.txt files for this example."
Comment utiliser Fuzzlyn Triage (.NET)
1
Copie le prompt
Un clic copie le prompt packagé (ou l'envoie à ton agent).
2
L'agent installe le skill
Il ajoute le SKILL.md et ses ressources à ton projet.
3
Activation automatique
Le skill s'active dès que le contexte correspond.
Déclencheurs pour Fuzzlyn Triage (.NET)
Dis simplement à ton agent quelque chose comme :
Applique le skill fuzzlyn-triage__dotnet-dotnet__src-runtime-github-skills-6afa0eb6ec9b à cette tâche
Utilise fuzzlyn-triage__dotnet-dotnet__src-runtime-github-skills-6afa0eb6ec9b pour améliorer cette implémentation
Passe en revue ce sujet avec fuzzlyn-triage__dotnet-dotnet__src-runtime-github-skills-6afa0eb6ec9b
Skills liés à Fuzzlyn Triage (.NET)
Add CLI Command (.NET)
Add or change a dotnet CLI command, subcommand, or option across the relevant CLI projects. USE FOR: adding or changing a dotnet CLI command/subcommand, adding a new Option<T> or Argument<T>, registering a subcommand in the command tree, changing an option's help description or a command's runtime message, wiring a command parser, or updating --help output.Add Dotnet Aot Command (.NET)
Add, enable, or review a dotnet CLI command or feature in the Native AOT CLI (src/Cli/dotnet-aot) and prove its compatibility. USE FOR: migrating a command or option to AOT, reviewing an AOT migration PR, defining conservative eligibility and managed fallback, changing AotSourceFiles.props or AotDependencies.props, validating AOT/managed parity, NativeAOT-publishing tests, checking binary-size impact, or using the dn harness and separated SDK layout. DO NOT USE FOR: resolving IL trim/AOT analyzer warnings alone (use dotnet-aot-compat), running dotnet.Tests incrementally (use incremental-test), or pure managed CLI work.Add Net Analyzer (.NET)
Add, port, or change a .NET code analysis rule (CA####) under src/Microsoft.CodeAnalysis.NetAnalyzers. USE FOR: implementing a new CA analyzer and its code fixer, porting a rule or PR from the retired dotnet/roslyn-analyzers repo, allocating a diagnostic ID from DiagnosticCategoryAndIdRanges.txt, choosing RuleLevel/severity/category, wiring resx + xlf strings, recording the rule in AnalyzerReleases.Unshipped.md, regenerating the analyzer documentation/sarif files, and writing MSTest analyzer/code-fix tests with the VerifyCS/VerifyVB harness. DO NOT USE FOR: NETSDK#### MSBuild diagnostics (src/Tasks), CS####/BC#### compiler diagnostics or IDE#### analyzers (dotnet/roslyn), or CONTAINER#### diagnostics (src/Containers).