Crash Similarity Scoring via Stack Traces and User Actions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing software testing methods fail to effectively identify and prioritize errors in software applications, particularly due to the complexity of stack traces and variations in user actions, which can lead to undetected issues in production environments.
Innovation Solution
A computer-implemented method that generates similarity scores between crash reports by comparing stack frames, user actions, and crash location information, allowing for the identification of similar errors and prioritization of error resolution, and includes blocking deployment until errors are resolved.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If stack traces are compared to identify errors, then error identification capability is improved, but the complexity of analyzing and prioritizing errors increases due to variations in stack traces and user actions
Solution Approach 1:
The patent segments the error analysis process into multiple independent similarity metrics: stack frame similarity, user action similarity, and crash location similarity. Each metric analyzes a specific aspect of the crash report independently, then combines them to produce an overall similarity score. This segmentation reduces the complexity of analyzing entire stack traces by breaking them down into manageable components.
Solution Approach 2:
The patent transforms the error analysis from qualitative comparison to quantitative scoring by introducing similarity metrics that produce numerical values. Instead of manually comparing stack traces, the system calculates similarity scores based on defined parameters (stack frame matches, user action matches, location matches), enabling automated prioritization and reducing analysis complexity.
2Reliability
If comprehensive testing is performed to ensure application reliability, then software quality is improved, but testing time and resources increase
Solution Approach 1:
The patent implements preliminary action by analyzing crash reports from production environments and using those insights to guide future testing. The system identifies patterns in crash data and prioritizes testing of areas with high crash frequency or severity, allowing testing resources to be allocated more efficiently before deployment.
Solution Approach 2:
The patent establishes a feedback loop where crash reports from production are continuously analyzed and fed back into the testing process. The similarity metrics compare new crash reports against historical data, providing feedback on which errors are most common or severe, thereby guiding subsequent testing priorities to improve reliability more effectively.
3Measurement precision
If all crash reports are analyzed in detail, then error prioritization accuracy is improved, but processing time and computational resources increase
Solution Approach 1:
The patent applies partial action by analyzing only the most relevant aspects of crash reports rather than every detail. The system calculates similarity scores based on key metrics (stack frames, user actions, location) and uses these partial analyses to prioritize errors, avoiding the need to fully examine every crash report in exhaustive detail while still achieving accurate prioritization.
Solution Approach 2:
The patent replaces manual mechanical analysis of crash reports with automated computational similarity metrics. Instead of developers manually reviewing each crash trace, the system uses algorithmic comparison of stack frames, user actions, and crash locations to automatically generate prioritized error lists, significantly improving processing efficiency.
Data Source
AI summary
Certain aspects of the present disclosure provide techniques for determining crash similarity based on stack traces and user actions associated with a crash event and handling crash events based on the determined crash similarity. An example method generally includes receiving a crash report for a crash event recorded during execution of a software application. A similarity score is generated between the received crash report and one or more historical crash reports associated with historical crash events recorded during execution of the software application. A target set of historical crash reports is selected based on the generated similarity scores for each respective historical crash report. The target set of historical crash reports generally includes crash reports having generated similarity scores exceeding a threshold similarity score. One or more actions are taken to process the received crash report based on the target set of historical crash reports.