Defect management method based on function call stack backtracking and crash sample clustering
By using function call stack backtracking and crash sample clustering, the problem of difficult defect localization in complex mobile applications is solved, achieving an efficient closed loop for defect management and improving the accuracy and automation of defect management.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINESE PEOPLES LIBERATION ARMY UNIT 61660
- Filing Date
- 2026-05-15
- Publication Date
- 2026-07-21
AI Technical Summary
Existing technologies face difficulties in defect localization in complex mobile applications and parallel testing environments, especially in asynchronous callbacks, thread switching, and cross-component calls. The readability and comparability of the call stack are poor, code obfuscation makes defect comparison difficult, and the lack of automated reproduction capabilities leads to low defect management efficiency.
By subscribing to and collecting crash signals, recording metadata, loading symbol files to recover method names and source code line numbers, generating robust signatures, concatenating call paths, and combining event sequences to automatically generate replayable POC scripts and structured reports, automatic clustering and localization of crash clusters can be achieved.
It improves the accuracy of defect deduplication and aggregation, enhances the ability to reproduce and locate defects, supports cross-version testing, shortens the time for defect location and reproduction, and improves the automation level and overall quality of defect management.
Smart Images
Figure CN122432047A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of testing technology, specifically relating to a defect management method based on function call stack backtracking and crash sample clustering. Background Technology
[0002] In software development and testing, application crashes and unresponsive behavior (ANR) are key defect types that affect user experience and product stability. Common defect localization methods rely on logging and call stack analysis, but these present significant challenges in complex mobile applications and parallel testing environments.
[0003] (1) The same function may be triggered by multiple entry points, and different account statuses and language / theme switching will also introduce interface differences, increasing the complexity of defect reproduction.
[0004] (2) Asynchronous callbacks, thread switching and cross-component calls cause the causal chain to be cut into multiple fragments, lacking an overall execution context.
[0005] (3) The Java / Native hybrid stack and multi-process collaborative operation further reduce the readability and comparability of the call stack.
[0006] (4) Code obfuscation (such as R8 / ProGuard) and multi-dex layout cause method signatures and line numbers to drift, making cross-version defect comparison more difficult.
[0007] Therefore, although the call stack can record the function execution path when an exception is triggered, in real-world scenarios, there are often problems such as fragmented evidence, lack of comparability, and difficulty in clustering and attribution, which directly leads to a longer defect management and repair cycle.
[0008] Existing defect collection and management technologies mainly focus on crash log collection, symbolic reconstruction, and simple deduplication statistics. Typical examples include tools such as Crashpad / Breakpad, Crashlytics, ACRA, and Sentry. These solutions are widely used in mobile application defect management and share many similarities with this invention, making them the closest existing technologies.
[0009] Their common technical features are mainly reflected in: Capable of capturing exception information and function call stacks during application runtime; The obfuscated method names and line numbers are restored to their source code locations through symbolic mapping. Deduplication and statistical analysis are performed based on shallow features (such as anomaly type and top-level stack frame); Provide defect overviews and trend monitoring in the form of reports and dashboards.
[0010] These methods constitute the closest existing technical solution for defect collection and management; Currently widely used crash collection and analysis systems include Crashpad / Breakpad, Crashlytics, ACRA, Sentry, etc. Their core implementation idea is: Exception information and call stack are captured during application runtime and mapped to restore method names and source code locations; The collected crash samples were deduplicated and statistically analyzed based on "exception type + top-level stack frame". It provides crash frequency, device information, and basic reports to help developers manually locate problems. The process can be roughly represented as follows: exception capture → call stack collection → symbolic restoration → deduplication based on top-level frame → generation of statistical reports.
[0011] However, this type of existing technology has the following shortcomings: 1. The deduplication rules rely too much on shallow features (such as anomaly type and top-level stack frame), which leads to the splitting of defects with the same origin and the merging of defects with different origin, resulting in unstable clustering results.
[0012] 2. The lack of systematic pruning of noisy frames in whitelists / blacklists makes it easy to mistakenly use third-party library or system call frames as the basis for clustering, affecting accuracy.
[0013] 3. It cannot adapt to cross-version code obfuscation and method signature drift, has limited ability to manage its family of defects, and its historical knowledge is difficult to reuse.
[0014] 4. Lack of deep integration with upstream parallel testing makes it impossible to bind crash samples to event sequences, page states, and lifecycle trajectories, resulting in insufficient reproducibility and requiring extensive manual trial and error for defect localization.
[0015] 5. Lack of automated scenario reproduction and script export capabilities prevents the formation of a closed loop of "detection-backtracking-reproduction-reporting," leaving defect management at the level of alarms and statistics. Summary of the Invention
[0016] To overcome the shortcomings of existing technologies, this invention provides a defect management method based on function call stack backtracking and crash sample clustering. The method includes: subscribing to and collecting Java exceptions, ANRs, and native crash signals; recording timestamps, thread names, device fingerprints, and APK / SDK version metadata; encapsulating these as "crash sample units"; loading the corresponding version's mapping file and NDK (Native Development Kit) symbols; restoring method names and source code line numbers; and performing path normalization and noise frame trimming; splicing scattered call fragments to generate a complete trigger path; generating robust signatures based on exception type, TopK keyframes, trigger path hashes, and environment summaries; performing similarity calculations and configurable threshold clustering in the signature space to merge originating or similar crashes into "crash clusters"; selecting representative samples for each cluster; and automatically generating replayable PoC scripts and structured reports by combining event sequences, page states, and lifecycle trajectories. This invention improves the accuracy of defect deduplication and aggregation and enhances defect reproduction and localization capabilities.
[0017] The technical solution adopted by this invention to solve its technical problem is as follows: Step 1: Subscribe to and collect Java exception, ANR and native crash signals, record timestamps, thread names, device fingerprints, APK / SDK version metadata, and encapsulate them into "crash sample units"; Step 2: Load the mapping file of the target application version corresponding to the crash sample unit and the symbol file of the corresponding Native Development Kit (NDK) build artifact, restore the obfuscated method names and native symbols in the crash call stack, restore the method names and source code line numbers corresponding to each call frame in the target application crash call stack, and perform path normalization and noise frame clipping. Step 3: Piece together the scattered call fragments to generate a complete trigger path; Step 4: Generate a robust signature; Step 5: Perform similarity calculation and configurable threshold clustering in the signature space to merge homologous or similar crashes into "crash clusters"; Step 6: Select representative samples for each cluster, and automatically generate a replayable POC script and structured report by combining event sequences, page states, and lifecycle trajectories.
[0018] Preferably, step 3 is performed in a multi-threaded, asynchronous callback, or cross-component scenario.
[0019] Preferably, the robust signature is generated based on the exception type, TopK keyframes, trigger path hash, and environment digest.
[0020] A defect management system based on function call stack backtracking and crash sample clustering includes: Crash capture and sample building module: Subscribes to and collects Java exceptions, ANRs and native crash signals, records timestamps, thread names, device fingerprints and APK / SDK version metadata, and encapsulates them into "crash sample units"; Symbolization and deobfuscation module: Loads the corresponding version of the mapping file and NDK symbols, restores the method name and source code line number, and performs path normalization and noise frame clipping; Call path backtracking module: In multi-threaded, asynchronous callback, or cross-component scenarios, it splices together scattered call fragments to generate a complete trigger path; Anomaly signature generation module: Generates robust signatures based on anomaly type, TopK keyframes, trigger path hash, and environment digest; Crash Sample Clustering Module: Performs similarity calculation and configurable threshold clustering in the signature space, merging homologous or similar crashes into "crash clusters"; Reproduction and Reporting Module: Selects representative samples for each cluster, and automatically generates replayable POC scripts and structured reports by combining event sequences, page states, and lifecycle trajectories.
[0021] An electronic device includes a processor and a memory; the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory to cause the electronic device to perform the above-described defect management method.
[0022] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned defect management method.
[0023] A chip includes a processor for retrieving and running a computer program from a memory, causing a device on which the chip is installed to perform the aforementioned defect management method.
[0024] A computer program product includes a computer storage medium storing a computer program, the computer program including instructions executable by at least one processor, which, when executed by the at least one processor, implement the aforementioned defect management method.
[0025] The beneficial effects of this invention are as follows: 1. Improved accuracy of defect deduplication and aggregation: This invention generates robust exception signatures through function call stack backtracking and keyframe normalization, avoiding the problems of incorrect splitting and merging caused by relying solely on exception types or top-level stack frames in existing technologies. Therefore, in cross-thread, cross-component, and cross-version scenarios, crash samples can be accurately clustered, significantly improving the purity and stability of defect merging.
[0026] 2. Enhanced Defect Reproduction and Localization Capabilities: Based on clustering results, this invention automatically exports executable POC scripts, combining event sequences, page states, and lifecycle trajectories to form a complete chain of evidence. This enables crash issues not only to be collected but also to be stably reproduced and quickly located. This effectively reduces the cost of manual backtracking and trial and error.
[0027] 3. Supports cross-version and large-scale testing scenarios: Through version-aware symbolization and environment fingerprint management, this invention maintains high reusability even with minor version differences during frequent application iterations, enabling the migration and reuse of historical knowledge. Furthermore, this method possesses parallel processing and incremental merging capabilities, allowing for stable operation in parallel testing environments with thousands of nodes, thus adapting to large-scale engineering scenarios.
[0028] 4. Reduced manual screening and maintenance costs: Compared to existing crash collection platforms, this invention not only provides basic statistics but also transforms scattered logs into structured defect assets, automatically generating reports and remediation suggestions, reducing the time investment in manual analysis. Verified results show that the time for locating and reproducing a single defect can be reduced from the traditional 40–60 minutes to approximately 8–12 minutes.
[0029] 5. Improve overall quality measurement and defect management efficiency: This invention fully integrates the processes of "collection—backtracking—signature—clustering—reproduction—reporting" to achieve a closed-loop engineering model for defect management. Through automated clustering and evidence chain generation, the testing platform can more quickly identify high-risk defects and assist the development team in prioritizing them, thereby improving overall software quality and iteration efficiency. Attached Figure Description
[0030] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation
[0031] The present invention will be further described below with reference to the accompanying drawings and embodiments.
[0032] The purpose of this invention is: 1. Without relying on the source code, the function call stack backtracking is used to reconstruct the call path across threads, modules, and versions, and the noisy frames are normalized and pruned to improve the comparability and readability of the call stack.
[0033] 2. Implement automatic clustering analysis of crash samples, generate robust signatures based on anomaly type, keyframe normalization features, trigger path hash, and environment summary, thereby achieving cross-version consistent aggregation and defect family management.
[0034] 3. Bind clustering results with test event sequences, page states, and lifecycle trajectories to automatically generate reproducible scenarios and structured reports, thus creating an engineering closed loop of defect collection, backtracking, clustering, reproduction, and reporting.
[0035] like Figure 1 As shown, this invention proposes a defect management method based on function call stack backtracking and crash sample clustering. The overall concept is to link crash collection, stack symbolization and deobfuscation, call path backtracking, exception signature generation, cross-version sample clustering, representative sample selection and reproduction script generation into a closed loop, solving the problems of scattered crash samples, inaccurate deduplication, incomparability across versions, and lack of reproducibility in existing technologies.
[0036] The system architecture is divided into the following key modules: 1. Crash Capture and Sample Building Module: Subscribes to and collects Java exceptions, ANRs, and native crash signals, records metadata such as timestamps, thread names, device fingerprints, and APK / SDK versions, and encapsulates them into "crash sample units".
[0037] 2. Symbolization and Deobfuscation Module: Loads the corresponding version of the mapping file and NDK symbols, restores method names and source code line numbers, and performs path normalization and noise frame clipping.
[0038] 3. Call Path Backtracking Module: In multi-threaded, asynchronous callback, or cross-component scenarios, it splices together scattered call fragments to generate a complete trigger path.
[0039] 4. Anomaly Signature Generation Module: Generates robust signatures based on anomaly type, TopK keyframes (normalized), trigger path hash, and environment digest to resist the impact of minor version differences and obfuscation.
[0040] 5. Crash Sample Clustering Module: Performs similarity calculation and configurable threshold clustering in the signature space, merging homologous or similar crashes into "crash clusters".
[0041] 6. Reproduction and Reporting Module: Select representative samples for each cluster, and automatically generate replayable POC scripts and structured reports by combining event sequences, page states, and lifecycle trajectories.
[0042] This invention can be integrated into a parallel GUI testing platform. In black-box mode, it can run by relying solely on crash logs, while in gray-box mode, it can be combined with lifecycle callbacks and lightweight instrumentation to improve accuracy.
[0043] Example 1: Open source application testing scenario; Several open-source Android applications are run in a parallel testing system. Random event sequences are generated through automated exploration tools, and the system automatically captures and manages crashes. The specific implementation process is as follows: Step 1: During application runtime, the CrashTrace module captures Java exceptions, ANRs, and native crash signals in real time, and records metadata such as thread name, timestamp, device, and APK version to form raw crash sample units.
[0044] Step 2: Load the corresponding version of the mapping file and symbol table, symbolize and deobfuscate the call stack, and restore the method name and source code line number.
[0045] Step 3: Trim log frames and noisy frames such as reflection calls, and piece together the scattered stack segments into a complete call path based on temporal proximity and triggering events.
[0046] Step 4: Generate robust exception signatures (exception type + TopK stack frames + trigger path hash + environment digest) to ensure cross-version comparability.
[0047] Step 5: Calculate similarity and cluster within the signature space, merging homologous crash samples into crash clusters.
[0048] Step 6: Automatically select representative samples for each crash cluster, combine them with the original event sequence to generate an executable POC script, and export a structured report containing call paths, stack frame comparisons, and repair suggestions.
[0049] This embodiment demonstrates that the present invention can transform scattered crash logs into reproducible defect assets in large-scale testing scenarios of open-source applications, thereby improving deduplication and localization efficiency.
[0050] Example 2: Enterprise application iteration scenario; In the continuous iteration and rapid minor version updates of enterprise applications, crashes often occur due to API changes or configuration differences. The application process of this invention in this scenario is as follows: Step 1: When running the latest iteration on the parallel GUI test platform, the system captures crash signals and records metadata, forming crash sample units.
[0051] Step 2: Restore the call stack information using the version isolation symbolization mechanism, and perform black / white list filtering and keyframe normalization.
[0052] Step 3: Piece together the scattered stack segments across threads and components into a complete trigger path to ensure context integrity.
[0053] Step 4: Generate robust exception signatures that support cross-version comparison and reuse of historical knowledge.
[0054] Step 5: Perform clustering in the signature space to unify and merge issues with the same origin, avoiding them from being mistakenly split into multiple numbers due to differences in entry points.
[0055] Step 6: Output the POC script representing the sample and generate a structured report containing the trigger path, environmental fingerprint, and remediation suggestions to support rapid regression verification and defect closed-loop management.
[0056] This embodiment demonstrates that the present invention can effectively solve the problem of cross-version merging and location difficulties in the rapid iteration environment of enterprise-level applications, making defect management more stable and efficient.
Claims
1. A defect management method based on function call stack backtracking and crash sample clustering, characterized in that, Includes the following steps: Step 1: Subscribe to and collect Java exception, ANR and native crash signals, record timestamps, thread names, device fingerprints, APK / SDK version metadata, and encapsulate them into "crash sample units"; Step 2: Load the mapping file of the target application version corresponding to the crash sample unit and the symbol file of the corresponding NDK build artifact, restore the obfuscated method names and native symbols in the crash call stack, restore the method names and source code line numbers corresponding to each call frame in the target application crash call stack, and perform path normalization and noise frame clipping. Step 3: Piece together the scattered call fragments to generate a complete trigger path; Step 4: Generate a robust signature; Step 5: Perform similarity calculation and configurable threshold clustering in the signature space to merge homologous or similar crashes into "crash clusters"; Step 6: Select representative samples for each cluster, and automatically generate a replayable POC script and structured report by combining event sequences, page states, and lifecycle trajectories.
2. The defect management method based on function call stack backtracking and crash sample clustering according to claim 1, characterized in that, Step 3 is performed in multi-threaded, asynchronous callback, or cross-component scenarios.
3. The defect management method based on function call stack backtracking and crash sample clustering according to claim 1, characterized in that, The robust signature is generated based on the exception type, TopK keyframes, trigger path hash, and environment digest.
4. A defect management system employing the defect management method as described in claim 1, characterized in that, include: Crash capture and sample building module: Subscribes to and collects Java exceptions, ANR and native crash signals, records timestamps, thread names, device fingerprints, APK / SDK version metadata, and encapsulates them into "crash sample units"; Symbolization and deobfuscation module: Loads the corresponding version of the mapping file and NDK symbols, restores the method name and source code line number, and performs path normalization and noise frame clipping; Call path backtracking module: In multi-threaded, asynchronous callback, or cross-component scenarios, it splices together scattered call fragments to generate a complete trigger path; Anomaly signature generation module: Generates robust signatures based on anomaly type, TopK keyframes, trigger path hash, and environment digest; Crash Sample Clustering Module: Performs similarity calculation and configurable threshold clustering in the signature space, merging homologous or similar crashes into "crash clusters"; Reproduction and Reporting Module: Selects representative samples for each cluster, and automatically generates replayable POC scripts and structured reports by combining event sequences, page states, and lifecycle trajectories.
5. An electronic device, characterized in that, include: Processor and memory; The memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory to cause the electronic device to perform the method as described in any one of claims 1 to 4.
6. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 4.
7. A chip, characterized in that, include: A processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1 to 4.
8. A computer program product, characterized in that, The computer program product includes a computer storage medium storing a computer program, the computer program including instructions executable by at least one processor, which, when executed by the at least one processor, implement the method as described in any one of claims 1 to 4.