Bug Localization and Fix Skill
Overview
Through a structured error analysis and root cause localization process, automatically generate minimized diff-format fix patches and regression-preventive test cases, enabling end-to-end automated processing from error symptoms to complete fix solutions.
Application Scenarios
- Need analysis when encountering error symptoms such as program crashes, exception throws, test failures, etc.
- Need to locate the root cause of bugs (especially issues introduced by code changes)
- Need to generate code fix patches that comply with engineering specifications
- Need to create executable regression-preventive test cases
- Need a complete bug analysis report (including root cause, fix, testing, and prevention suggestions)
Quick Reference
| Scenario | Localization Method | Applicable Conditions |
|---|
| General bug analysis | Top-down tracing method | No clear code change/PR information |
| Bug introduced by code change | Git bisect method | Has code_change_info, needs to locate specific PR/commit |
| Error Code | Meaning | Handling Method |
|---|
| E001 | Missing or unparseable input information | Supplement required inputs (error_phenomenon/reproduce_steps) |
| E002 | Ambiguous root cause that cannot be accurately located | Provide more context information or code change information |
| E003 | Patch generation failed | Confirm root cause is locked, check code context |
| E004 | Test case generation failed | Confirm fix patch is valid, specify test framework |
Core Capabilities (Action + Result, No Overlap/Out-of-Scope)
- Parse multi-language error symptoms, verify the completeness and validity of required input information
- Use the top-down tracing method for general scenarios and the Git bisect method for code change/PR scenarios to locate bug root causes, and verify the reproducibility of the root cause
- Generate minimized diff-format code fix patches for the root cause, verify patch syntax correctness, and follow engineering development specifications
- Create directly executable regression-preventive test cases for mainstream test frameworks, covering core normal/boundary/exception scenarios
- Output structured Markdown-format bug analysis reports, including error symptom descriptions, reproduction steps, root cause analysis, fix patches, test cases, and prevention suggestions
Workflow (Steps + Verification + Interruption + Feedback, Executable by Agent)
Step 1: Information Collection and Verification
✅ Checkpoint: Verify whether required inputs (error_phenomenon/reproduce_steps) are complete and recognizable
❌ Interrupt Condition: Missing required inputs / Unparseable error symptoms (e.g., garbled text, incomplete content) → Throw error code E001 and interrupt
📝 Feedback: Output "Information collection completed, can proceed to root cause analysis stage / Missing required inputs, error code E001"
Step 2: Root Cause Analysis and Confirmation
✅ Checkpoint: Root cause is reproducible and accurately locked to specific code lines/files/PR/commit records
❌ Interrupt Condition: Insufficient information leads to ambiguous root cause that cannot be accurately located → Throw error code E002 and interrupt
📝 Feedback: Output "Root cause located: XXX (associated PR/commit: XXX) / Ambiguous root cause, error code E002"
Localization Methods (Agent automatically selects based on input, enhances Git bisect method for PR/commit localization)
Method 1: Top-down Tracing Method (General scenario, no clear code change/PR information)
- Analyze error stack traces to locate the specific code line/file where the exception is thrown/error is triggered
- Check whether the input parameters, data flow, and dependency calls at this location meet business expectations
- If there are exceptions in input/dependencies, trace upstream to the data source/caller level by level
- Repeat the above steps until the root cause is found (the location where data/logic first deviates from expectations)
Method 2: Git Bisect Localization (Scenario where bug is introduced by code change/PR, core is to locate problematic PR/commit)
- Based on the input code_change_info, confirm the last normal version/PR/commit where the bug did not occur and the abnormal version/PR/commit where the bug first occurred
- Execute Git bisect commands in sequence: →
git bisect bad [abnormal version/commit hash]
git bisect good [normal version/commit hash]
- Git automatically narrows down the investigation scope and locates the specific commit record/associated PR that introduced the bug (the only change record in the bisect result)
- Analyze the code change content of the target commit/PR, lock the root cause code line, and verify: after rolling back this commit/PR, confirm whether the bug disappears
- If multiple PRs/commits are involved, sort them by impact level and provide a method for verification one by one
Step 3: Minimized Diff-format Patch Generation and Verification
✅ Checkpoint: Patch is in standard diff format, minimal modification granularity, no syntax errors, and only fixes the root cause
❌ Interrupt Condition: Root cause not locked / No valid code context → Throw error code E003 and interrupt
📝 Feedback: Output "Diff-format fix patch generated, total X changes / Patch generation failed, error code E003"
Patch Generation Principles (Mandatory Compliance)
- Minimal modification: Only modify code related to the root cause, no irrelevant logic/format changes
- Root cause fix: Address the essence of the problem, rather than temporarily circumventing surface issues
- Defensive programming: Add input validation, boundary judgment, exception capture logic when necessary
- Engineering specifications: Comply with project coding specifications, do not introduce new syntax/logic issues
- Traceability: Add single-line comments at key fix points to explain the fix reason and associated root cause
Step 4: Regression-preventive Test Case Generation and Verification
✅ Checkpoint: Test cases are directly executable, cover core scenarios related to the root cause, and match the test framework actually used by the project
❌ Interrupt Condition: No valid fix patch / Test framework not specified → Throw error code E004 and interrupt
📝 Feedback: Output "Regression-preventive test cases generated, total X (adapted to XXX framework) / Test case generation failed, error code E004"
Core Requirements for Test Cases
- Reproducible: Can accurately reproduce the original bug (fails before fix)
- Verifiable: Passes after fix, can effectively verify the patch's fix effect
- Full coverage: Covers normal scenarios, boundary scenarios, and exception scenarios related to the root cause
- Executable: No syntax errors, adapts to mainstream test frameworks (gtest/pytest/JUnit/GoTest/Jest/Vue Test Utils)
Output Format (Structured Markdown, Friendly to Both Machines and Humans, Fixed Template Cannot Be Modified Randomly)
Bug Analysis Report
1. Error Symptoms
- Error Description: [Clearly describe error type, error message, impact scope, associated business scenario]
- Reproduction Steps: [Step-by-step reproduction method, including runtime environment, test data, operation steps, associated version]
- Input Validation: [Pass/Fail, if failed, mark error code + specific reason]
- Code Change Information: [PR/commit/branch information extracted from input, mark key information of bisect localization]
2. Root Cause Analysis
- Root Cause Localization: [Specific root cause, such as division by zero error/null pointer exception/logic judgment error, mark hash/number if associated with PR/commit]
- Localization Method: [Top-down tracing method / Git bisect method (associated PR: XXX, commit hash: XXX)]
- Tracing Process: [Briefly describe the execution process of data flow/call chain/Git bisect, mark key steps that locked the root cause]
- Impact Scope: [Affected code modules/PRs/branches/business scenarios/user groups]
3. Minimized Diff-format Fix Patch
[Standard diff format, including file path, line number, modified content, add comments at key fix points to explain]
diff
diff --git a/.github/workflows/nightly_benchmarks.yaml b/.github/workflows/nightly_benchmarks.yaml
index 123456..789abc 100644
--- a/.github/workflows/nightly_benchmarks.yaml
+++ b/.github/workflows/nightly_benchmarks.yaml
@@ -15,6 +15,10 @@
- name: Install dependencies
run: |
pip install -e .
+ # Install msprobe-related dependencies (Root cause fix: msprobe feature introduced by PR#4241 requires these dependencies)
+ pip install mindstudio-probe==8.3.0 || echo "msprobe installation skipped"
+ pip install tb_graph_ascend || echo "tb_graph_ascend installation skipped"
4. Regression-preventive Test Cases
[Executable test code, adapted to the test framework actually used by the project, covering normal/boundary/exception scenarios]
python
# Example: pytest framework test case
def test_bug_fix_reproduction():
"""Reproduce the original bug (fails before fix)"""
# Test code...
assert result == expected
def test_bug_fix_validation():
"""Verify fix effect (passes after fix)"""
# Test code...
assert fixed_result == expected
def test_edge_cases():
"""Boundary scenario test"""
# Test code...
pass
5. Prevention Suggestions
- Code Level: [Code improvement suggestions targeting the root cause, such as adding parameter validation, exception handling, etc.]
- Process Level: [Development process improvement suggestions, such as code review key points, test coverage requirements, etc.]
- Tool Level: [Tool or monitoring suggestions, such as static analysis, log enhancement, etc.]