Merge remote-tracking branch 'origin/master' into vandonr/process3

Author: vandonr

.azure-pipelines/ultimate-pipeline.yml

@@ -143,7 +143,7 @@ variables:
   DD_LOGGER_DD_TAGS: test.configuration.job:$(System.JobDisplayName)
   DD_LOGGER_ENABLED: true
   DD_COLLECTOR_CPU_USAGE: true
-  ToolVersion: 3.35.0
+  ToolVersion: 3.36.0
   # .NET SDK performance optimization variables
   DOTNET_SKIP_FIRST_TIME_EXPERIENCE: 1
   DOTNET_CLI_TELEMETRY_OPTOUT: 1
@@ -1710,12 +1710,25 @@ stages:
         SampleName: $(IntegrationTestSampleName)
 
     - script: tracer\build.cmd RunIntegrationTests RunWindowsRegressionTests -Framework $(framework) --code-coverage-enabled $(CodeCoverageEnabled)
-      displayName: Run integration tests
+      displayName: Run integration tests (Tracer)
+      condition: ne(variables['area'], 'ASM')
+      env:
+        DD_LOGGER_DD_API_KEY: $(ddApiKey)
+        enable_crash_dumps: true
+        Filter: $(IntegrationTestFilter)
+        SampleName: $(IntegrationTestSampleName)
+        Area: $(area)
+
+    - script: tracer\build.cmd RunIntegrationTests RunWindowsRegressionTests -Framework $(framework) --code-coverage-enabled $(CodeCoverageEnabled)
+      displayName: Run integration tests (ASM)
+      condition: eq(variables['area'], 'ASM')
+      retryCountOnTaskFailure: 2
       env:
         DD_LOGGER_DD_API_KEY: $(ddApiKey)
         enable_crash_dumps: true
         Filter: $(IntegrationTestFilter)
         SampleName: $(IntegrationTestSampleName)
+        Area: $(area)
 
 #    TODO: Re-enable test-agent.windows once VM images are updated (hitting rate limits for docker)
 #    - script: docker compose -f docker-compose.windows.yml down
@@ -2272,7 +2285,26 @@ stages:
           -e SampleName=$(IntegrationTestSampleName) \
           -e Area=$(area) \
           IntegrationTests
-      displayName: docker-compose run IntegrationTests
+      displayName: docker-compose run IntegrationTests (Tracer)
+      condition: ne(variables['area'], 'ASM')
+      env:
+        DD_LOGGER_DD_API_KEY: $(ddApiKey)
+        baseImage: $(baseImage) # for interpolation in the docker-compose file
+
+    - script: |
+        docker-compose -f docker-compose.yml -p $(DockerComposeProjectName) \
+          run --no-deps --rm \
+          -e baseImage=$(baseImage) \
+          -e framework=$(publishTargetFramework) \
+          -e CodeCoverageEnabled=$(CodeCoverageEnabled) \
+          -e IncludeTestsRequiringDocker=false  \
+          -e Filter=$(IntegrationTestFilter) \
+          -e SampleName=$(IntegrationTestSampleName) \
+          -e Area=$(area) \
+          IntegrationTests
+      displayName: docker-compose run IntegrationTests (ASM)
+      condition: eq(variables['area'], 'ASM')
+      retryCountOnTaskFailure: 2
       env:
         DD_LOGGER_DD_API_KEY: $(ddApiKey)
         baseImage: $(baseImage) # for interpolation in the docker-compose file
@@ -4511,32 +4543,32 @@ stages:
           sampleName: Computer01
           testName: cpu-walltime
           poolName: ProfilerExecBenchAgent1
-          framework: net7.0
+          framework: net10.0
         Exceptions:
           sampleName: ExceptionGenerator
           testName: exceptions
           poolName: ProfilerExecBenchAgent2
-          framework: net7.0
+          framework: net10.0
         Contention:
           sampleName: Computer01
           testName: contention
           poolName: ProfilerExecBenchAgent3
-          framework: net7.0
+          framework: net10.0
         Allocations:
           sampleName: Computer01
           testName: allocations
           poolName: ProfilerExecBenchAgent4
-          framework: net7.0
+          framework: net10.0
         LiveHeap:
           sampleName: Computer01
           testName: liveheap
           poolName: ProfilerExecBenchAgent5
-          framework: net7.0
+          framework: net10.0
         GarbageCollections:
           sampleName: Computer01
           testName: garbagecollections
           poolName: ProfilerExecBenchAgent11
-          framework: net7.0
+          framework: net10.0
     pool:
       name: $(poolName)
     timeoutInMinutes: 30 #default value
@@ -4605,32 +4637,32 @@ stages:
           sampleName: Computer01
           testName: cpu-walltime
           poolName: ProfilerExecBenchAgent6
-          framework: net7.0
+          framework: net10.0
         Exceptions:
           sampleName: ExceptionGenerator
           testName: exceptions
           poolName: ProfilerExecBenchAgent7
-          framework: net7.0
+          framework: net10.0
         Contention:
           sampleName: Computer01
           testName: contention
           poolName: ProfilerExecBenchAgent8
-          framework: net7.0
+          framework: net10.0
         Allocations:
           sampleName: Computer01
           testName: allocations
           poolName: ProfilerExecBenchAgent9
-          framework: net7.0
+          framework: net10.0
         LiveHeap:
           sampleName: Computer01
           testName: liveheap
           poolName: ProfilerExecBenchAgent10
-          framework: net7.0
+          framework: net10.0
         GarbageCollections:
           sampleName: Computer01
           testName: garbagecollections
           poolName: ProfilerExecBenchAgent12
-          framework: net7.0
+          framework: net10.0
     pool:
       name: $(poolName)
     timeoutInMinutes: 30 #default value

.claude/commands/analyze-crash.md

@@ -0,0 +1,204 @@
+# Stack Trace Crash Analysis for dd-trace-dotnet
+
+You are analyzing a crash stack trace for the dd-trace-dotnet repository. Perform a comprehensive investigation to help engineers understand and triage the crash. Focus on de-mystifying the crashing thread and explaining how the crash occurred.
+
+## Input Processing
+The user has provided a crash stack trace. Parse and analyze it systematically.
+
+## Analysis Workflow
+
+## GitHub Link Generation
+
+When referencing files in the dd-trace-dotnet repository, always provide clickable GitHub links in addition to local paths:
+
+**Format**:
+```
+[filename:line](https://github.com/DataDog/dd-trace-dotnet/blob/master/path/to/file#Lline)
+```
+
+**Examples**:
+- Single line: `[cor_profiler.cpp:1430](https://github.com/DataDog/dd-trace-dotnet/blob/master/tracer/src/Datadog.Tracer.Native/cor_profiler.cpp#L1430)`
+- Line range: `[rejit_handler.cpp:263-296](https://github.com/DataDog/dd-trace-dotnet/blob/master/tracer/src/Datadog.Tracer.Native/rejit_handler.cpp#L263-L296)`
+
+**When to use**:
+- All file:line references in Executive Summary
+- Stack Trace Classification table "Location" column (when file paths are available)
+- All code context section headings
+- Related Code section
+
+**Path construction**:
+- Base URL: `https://github.com/DataDog/dd-trace-dotnet/blob/master/`
+- Append the repository-relative path (strip `C:\Users\...\dd-trace-dotnet\` or similar prefixes)
+- Add `#L{lineNumber}` for single line or `#L{start}-L{end}` for ranges
+- Example: Local path `C:\Users\...\dd-trace-dotnet\tracer\src\Datadog.Tracer.Native\cor_profiler.cpp:1430` becomes `[cor_profiler.cpp:1430](https://github.com/DataDog/dd-trace-dotnet/blob/master/tracer/src/Datadog.Tracer.Native/cor_profiler.cpp#L1430)`
+
+### Phase 1: Parse & Classify Stack Frames
+
+Extract all stack frames and classify each one:
+
+**Classification Categories:**
+- **CLR Runtime**: Functions like `ReJitManager::`, `ProfToEEInterfaceImpl::`, `ICorProfiler*`, CLR DLL references (clr.dll, coreclr.dll, mscorwks.dll)
+- **dd-trace-dotnet Native**: Namespace patterns (`trace::`, `debugger::`, `fault_tolerant::`, `iast::`), or paths containing `Datadog.Tracer.Native`
+- **dd-trace-dotnet Managed**: References to `Datadog.Trace.dll!`
+- **External/Application**: Everything else (customer code, third-party libraries, framework code)
+
+Create a classification table showing frame number, type, location, and brief description.
+
+### Phase 2: Locate dd-trace-dotnet Code
+
+For each dd-trace-dotnet frame that includes file path and line number:
+
+1. **Extract and normalize path**: Remove build-specific prefixes
+   - Strip: `c:\mnt\`, `D:\a\_work\1\s\`, `/home/runner/work/dd-trace-dotnet/`, etc.
+   - Result should be relative to repo root: `tracer/src/Datadog.Tracer.Native/{filename}`
+
+2. **Find file in repository**:
+   - First try direct path match
+   - If not found, use Glob tool with pattern: `**/Datadog.Tracer.Native/**/{filename}`
+   - If still not found, try just the filename: `**/{filename}`
+
+3. **Read code with context**:
+   - Find the function containing the crash line
+   - Include 10-15 lines before the crash line
+   - Mark or highlight the actual crash line
+   - Include 5-10 lines after
+   - Show enough context to understand what the code is doing
+
+### Phase 3: Code Context Extraction
+
+For each critical dd-trace-dotnet frame:
+1. Show the function signature
+2. Include surrounding code (described in Phase 2)
+3. **Clearly mark the crash line** with a comment like `// >>> CRASH POINT <<<`
+4. Explain what this code does
+5. Explain why it crashed based on the evidence
+
+Format each code section as:
+```
+### Frame X: {function_name} ([{file}:{line}](GitHub link))
+
+​```cpp
+// {file}:{start_line}-{end_line}
+{code with crash line marked}
+​```
+
+**Analysis**: {Explanation of what this code does and why it failed}
+```
+
+### Phase 4: Reconstruct Crash Flow
+
+Build a narrative explaining the execution flow leading to the crash. This is the primary goal of the analysis - to help engineers understand what happened:
+
+1. **Entry point**: Where did execution start? (e.g., profiler callback, background thread loop)
+2. **Key operations**: What was the code trying to do?
+3. **Critical transitions**: Where did control flow between components?
+4. **Failure point**: Where and why did it crash?
+5. **Crash type**: Describe what type of crash this is (e.g., null pointer dereference, access violation, invalid module reference, race condition, etc.)
+
+Write this as a clear, step-by-step narrative that someone unfamiliar with the code can follow. Focus on explaining HOW the crash happened based on the evidence in the stack trace and code, without prescribing a specific fix.
+
+### Phase 5: Identify Related Code
+
+Use Bash tool with git commands to find relevant context, focusing on commits associated with PRs:
+
+1. Check recent commits to the affected files: `git log --oneline -10 {file}`
+2. Search for related changes: `git log --grep="crash" --grep="fix" --oneline -20` (use keywords relevant to the crash area)
+3. For each relevant commit, check if it's associated with a PR:
+   - Look for PR numbers in commit messages (e.g., "(#1234)" or "PR #1234")
+   - If found, construct PR link: `https://github.com/DataDog/dd-trace-dotnet/pull/{number}`
+4. Prioritize commits with PR associations - these have more context
+5. Look for similar code patterns in other files that might provide context
+
+**Focus on commits with PR links** - PRs provide valuable context including descriptions, discussions, and rationale that individual commits lack.
+
+## Output Format
+
+Generate a well-formatted markdown document with these sections:
+
+```markdown
+# Crash Analysis Report
+**Generated**: {ISO 8601 timestamp}
+
+## Executive Summary
+{2-3 sentence summary of what crashed and where in the code. Focus on demystifying the crash location and describing what the crashing thread was doing.}
+
+## Stack Trace Classification
+
+### Crashed Thread: #{thread_number}
+
+| # | Type | Location | Description |
+|---|------|----------|-------------|
+| 0 | {type} | {function/location} | {brief description} |
+| 1 | {type} | {function/location} | {brief description} |
+| ... | ... | ... | ... |
+
+{If multiple threads provided, note other interesting threads but focus on crashed thread}
+
+## Code Context
+
+{For each critical dd-trace-dotnet frame, show code with analysis}
+
+### Frame X: {function} ([{file}:{line}](GitHub link))
+
+​```cpp
+{code snippet with crash line marked}
+​```
+
+**Analysis**: {Explanation of what this code does}
+
+## Crash Flow Reconstruction
+
+{Step-by-step narrative explaining the execution flow from start to crash point}
+
+**Crash Type**: {Description of what type of crash this is - e.g., null pointer dereference, access violation, invalid module reference, race condition}
+
+**How it happened**: {Clear explanation of the sequence of events that led to the crash based on the stack trace and code analysis}
+
+## Related Code
+
+**Relevant PRs and commits**:
+- [#{PR number}](https://github.com/DataDog/dd-trace-dotnet/pull/{PR number}): {PR title/description} - {why relevant}
+- [#{PR number}](https://github.com/DataDog/dd-trace-dotnet/pull/{PR number}): {PR title/description} - {why relevant}
+
+{Only include commits without PR associations if they are particularly relevant}
+
+**Related code locations**:
+- [{file}:{line}](GitHub link) - {description}
+- [{file}:{line}](GitHub link) - {description}
+
+## Additional Context
+
+{Any additional useful context about the application environment, runtime, features in use, or relevant background}
+
+---
+*Analysis generated by Claude Code /analyze-crash command*
+*This analysis is intended to help understand and triage the crash. Engineers should review this analysis to determine if a code fix is needed.*
+```
+
+## Output File Management
+
+1. **Create output directory**:
+   - On Windows: Use `powershell.exe -NoProfile -Command 'New-Item -ItemType Directory -Force -Path (Join-Path $env:USERPROFILE ".claude\analysis") | Select-Object -ExpandProperty FullName'`
+   - On Linux/Mac: Use `mkdir -p ~/.claude/analysis && echo ~/.claude/analysis`
+   - **IMPORTANT**: On Windows, you MUST use single quotes around the PowerShell command to prevent bash from interpreting `$env:USERPROFILE`
+2. **Generate filename**: Use format `crash-analysis-{YYYYMMDD-HHMMSS}.md` (e.g., `crash-analysis-20250316-143022.md`)
+3. **Save file**: Write the markdown analysis to the file
+4. **Return path**: Tell the user the full path where the analysis was saved
+
+## Important Guidelines
+
+- **Focus on triage and understanding**: The goal is to help engineers understand HOW the crash happened, not to prescribe specific fixes
+- **Describe crash types**: It's okay to identify what type of crash this is (e.g., null pointer, race condition, invalid reference), but don't match against fixed "patterns"
+- **End at explanation**: Phase 4 (Crash Flow Reconstruction) should provide a clear explanation of how the crash occurred. Engineers will then decide on fixes
+- **No fix suggestions**: Do not suggest code changes, patches, or specific implementation fixes. Focus on analysis only
+- **Handle path variations gracefully**: Stack traces from different build environments will have different path prefixes
+- **Continue with missing information**: If a file can't be located, note this but continue the analysis with available information
+- **Focus on the crashed thread**: If multiple threads are provided, focus primarily on the crashed thread but mention other relevant threads
+- **Be concise but thorough**: Provide enough detail to understand the issue without unnecessary verbosity
+- **Always include GitHub links**: Every file:line reference should have a clickable GitHub link to master branch
+- **Prefer PR links over commits**: When git log finds relevant commits, prioritize those associated with PRs. Extract PR numbers from commit messages (e.g., "(#1234)") and link to the PR: `https://github.com/DataDog/dd-trace-dotnet/pull/{number}`. Only include standalone commit links if particularly relevant and not part of a PR
+- **Mark uncertainties**: If something is unclear or speculative, explicitly state this
+
+## Now Analyze
+
+Parse the stack trace provided by the user and follow the workflow above to generate a comprehensive crash analysis.