Failure Analysis and Study Mapping
← Oracle Analysis and Study Mapping
This page provides the extended analysis and complete study-level mapping for the failure types reported in the survey Fuzzing AI Systems: Foundations, Techniques, and Open Challenges.
RQ4 examines the types of failures exposed by fuzzing techniques for AI systems. Each selected study was classified according to its reported failure type. The categories are not mutually exclusive because some studies expose more than one kind of failure.
Failure-Type Distribution
| Failure type | Number of studies |
|---|---|
| Misclassification | 49 |
| Crash/runtime error | 33 |
| Numerical inconsistency | 29 |
| Security vulnerability | 8 |
| Safety violation | 6 |
| Performance bug | 2 |
| Behavioral inconsistency | 1 |
| Coverage deficiency | 1 |
| Incorrect or degraded code summarization | 1 |
| ADS inconsistent steering behavior | 1 |
| ADS safety/perception failure | 1 |
| Translation errors | 1 |
The complete clickable PID mapping is provided in the Detailed Study-Level Mapping section.
Misclassification
Misclassification is the most frequently reported failure type, appearing in 49 studies.
This category includes:
- incorrect predictions;
- changed labels;
- degraded task outputs;
- unstable decisions; and
- incorrect behavior triggered by generated, mutated, or semantically transformed inputs.
Misclassification is especially common in model-level fuzzing because many studies evaluate whether a fuzzed input changes or degrades model behavior.
Examples include:
- DeepHunter (P032), which treats a changed prediction between an original seed and its mutant as error-inducing behavior;
- CtrlFuzz (P012), which targets model-level failures caused by generated test inputs;
- DLRegion (P007);
- GradFuzz (P040); and
- DeepCNP (P004).
The dominance of misclassification reflects the strong representation of model-level testing in the corpus.
Crash and Runtime Errors
Crash/runtime errors appear in 33 studies.
This category includes:
- crashes;
- uncaught exceptions;
- assertion failures;
- segmentation faults;
- abnormal termination;
- compiler failures;
- invalid execution states; and
- other severe runtime errors.
These failures are common in framework/library and compiler/backend testing, where generated:
- API calls;
- tensor operations;
- model graphs;
- tensor programs;
- compiler inputs;
- intermediate representations; or
- backend executions
may reach invalid or poorly tested execution states.
Examples include:
- NNsmith (P001), which reports compiler crashes and other execution failures;
- DocTer (P017), which exposes severe DL API failures, including segmentation faults, floating-point exceptions, aborts, and bus errors;
- TzER (P046), which detects crashes and unexpected exceptions during tensor-compiler fuzzing;
- NeuRI (P006); and
- Ache-Fuzz (P011).
Crash/runtime failures remain important because they are directly observable and do not require a complete semantic specification.
However, crash-only detection may miss silent numerical, behavioral, or security-relevant defects.
Numerical Inconsistency
Numerical inconsistency appears in 29 studies.
This category includes:
- divergent outputs;
- inconsistent numerical results;
- unstable computations;
- optimization-induced differences;
- device-dependent divergence;
- backend inconsistency; and
- cross-implementation output mismatch.
It is especially important for framework/library and compiler/backend testing, where semantically equivalent executions may produce unexpectedly different results.
Examples include:
- TensorJSFuzz (P003);
- HIRGEN (P028), which detects inconsistent results across original, optimized, and semantically mutated high-level IRs;
- TzER (P046), which compares optimized and non-optimized executions;
- DeepDiffer (P091);
- D3 (P095); and
- FUEL (P082).
YANHUI (P023) is associated with both crash/runtime error and numerical inconsistency because framework-level model-optimization bugs may involve execution failures as well as inconsistent optimized behavior.
Numerical inconsistency requires careful interpretation because small floating-point or implementation-level differences may be acceptable, while larger or semantically meaningful differences may indicate defects.
Security Vulnerabilities
Security vulnerabilities appear in 8 studies.
This category includes security-relevant defects in:
- AI frameworks;
- DL libraries;
- APIs;
- operators;
- runtime components;
- model-serving infrastructure; or
- AI-enabled software.
Examples include:
Some of these studies report concrete vulnerabilities, including CVE-associated issues.
Although security vulnerabilities appear less frequently than misclassification, crashes, or numerical inconsistency, they are important because defects in AI software infrastructure can affect confidentiality, integrity, availability, and downstream applications.
Safety Violations
Safety violations appear in 6 studies.
This category captures failures that violate:
- task-level safety requirements;
- environment-level constraints;
- policy-level expectations;
- driving rules;
- collision-avoidance conditions; or
- other domain-specific safety requirements.
Safety violations are mainly associated with autonomous-driving, reinforcement-learning, and system-level AI applications.
Examples include:
- DriveFuzz (P066), which detects collisions, traffic infractions, immobility, and other safety-critical driving misbehavior;
- ReinSeed (P130);
- ScenarioFuzz-LLM (P127);
- the map-aware RL fuzzing approach (P125); and
- the RL testing and repair framework (P164).
Safety-oriented failures are fewer in number but highly important because they occur in systems where incorrect behavior may have real-world consequences.
Performance Bugs
Performance bugs appear in 2 studies:
These failures involve unexpected performance degradation, inefficient optimization behavior, or other execution-time anomalies.
Performance bugs show that AI fuzzing can expose quality problems beyond functional correctness.
Specialized and Domain-Specific Failures
Several failure categories appear only once but capture important target-specific behaviors.
Behavioral Inconsistency
DeepRoad (P049) reports behavioral inconsistency in an autonomous-driving setting.
Coverage Deficiency
DeepHC (P167) reports coverage deficiency as a target of its test-generation process.
Incorrect or Degraded Code Summarization
CoCoFuzzing (P180) reports degraded code-summarization behavior in neural code models.
ADS Inconsistent Steering Behavior
FuzzScene (P198) reports inconsistent steering behavior in autonomous-driving systems.
ADS Safety or Perception Failure
SimsV (P197) targets perception- and safety-related failures in simulated autonomous-driving scenarios.
Translation Errors
DiFuzzNMT (P193) reports translation errors in neural machine translation.
These categories show that AI fuzzing increasingly considers task-specific and domain-specific failures rather than only prediction errors or runtime crashes.
Relationship Between Testing Target and Failure Type
Failure type is closely related to the AI-system layer under test.
Model-Level Studies
Model-level studies mainly report:
- misclassification;
- prediction changes;
- robustness failures;
- behavioral inconsistency;
- numerical instability; and
- degraded task outputs.
These failures are centered on model behavior.
Framework/Library and Compiler/Backend Studies
Component-level studies more often report:
- crashes;
- runtime exceptions;
- assertion failures;
- numerical inconsistencies;
- performance bugs;
- operator defects; and
- security vulnerabilities.
These failures arise because fuzzing exercises executable software components, including APIs, tensor operations, compiler passes, optimization paths, backends, and runtime systems.
System-Level Studies
System-level studies report broader failures such as:
- safety violations;
- policy-level failures;
- trajectory problems;
- perception failures;
- steering inconsistencies; and
- other domain-specific behavioral errors.
This variation shows that a single failure definition is insufficient for all AI-system targets.
Multi-Label Failure Detection
Several studies expose more than one type of failure.
Examples include:
- HIRGEN (P028) — crash/runtime error + numerical inconsistency;
- TzER (P046) — crash/runtime error + numerical inconsistency
- performance bug;
- DeepHunter (P032) — misclassification + numerical inconsistency;
- YANHUI (P023) — crash/runtime error + numerical inconsistency; and
- the RL testing and repair framework (P164) — misclassification + safety violation.
These examples show that one fuzzing workflow may expose several kinds of defects.
Failure labels should therefore be interpreted as overlapping dimensions rather than mutually exclusive categories.
Main Findings
The failure analysis supports five main observations:
- Misclassification remains the dominant failure type, reflecting the strong emphasis on model-level fuzzing.
- Framework/library and compiler/backend fuzzing frequently expose crashes and numerical inconsistencies.
- Security and safety failures are less frequent but important for high-impact AI systems.
- Specialized failure categories show that AI fuzzing is expanding beyond prediction correctness.
- Failure detection is target-dependent and frequently multi-label.
Overall, the failure model in AI fuzzing must go beyond crashes and exceptions.
The corpus includes:
- incorrect predictions;
- runtime failures;
- numerical inconsistencies;
- security vulnerabilities;
- safety violations;
- performance bugs; and
- specialized domain-level failures.
This diversity indicates that models, frameworks/libraries, compiler backends, and integrated AI applications require different failure definitions and detection mechanisms.
Detailed Study-Level Mapping
Each PID below links to the corresponding entry in the Primary Studies catalogue, which provides the full title, authors, publication year, venue, BibTeX key, and DOI or publication link.
| Failure type | # Studies | Primary studies |
|---|---|---|
| Misclassification | 49 | P004, P007, P012, P018, P022, P024, P025, P027, P030, P031, P032, P033, P038, P039, P040, P042, P044, P050, P051, P058, P060, P061, P136, P137, P140, P142, P143, P146, P147, P152, P153, P154, P157, P158, P160, P162, P164, P169, P170, P172, P174, P176, P178, P182, P200, P201, P202, P204, P208 |
| Crash/runtime error | 33 | P001, P002, P005, P006, P010, P011, P013, P017, P019, P023, P026, P028, P034, P035, P036, P041, P046, P068, P069, P076, P077, P078, P079, P080, P081, P083, P088, P089, P096, P101, P103, P104, P133 |
| Numerical inconsistency | 29 | P003, P008, P009, P014, P015, P016, P020, P021, P023, P028, P029, P032, P036, P040, P046, P082, P086, P090, P091, P095, P099, P100, P106, P119, P120, P144, P145, P148, P156 |
| Security vulnerability | 8 | P043, P087, P111, P113, P114, P116, P121, P122 |
| Safety violation | 6 | P066, P125, P127, P130, P164, P165 |
| Performance bug | 2 | P045, P046 |
| Behavioral inconsistency | 1 | P049 |
| Coverage deficiency | 1 | P167 |
| Incorrect or degraded code summarization | 1 | P180 |
| ADS inconsistent steering behavior | 1 | P198 |
| ADS safety/perception failure | 1 | P197 |
| Translation errors | 1 | P193 |
Note: Categories are not mutually exclusive because some studies report multiple failure types.