Automatic Software Failure Diagnosis via Binary Analysis and Replay

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current in-production software failure diagnosis methods are inefficient, often requiring manual effort, expertise, and may not diagnose concurrency or sequential failures due to incomplete information, and raise privacy concerns with users.

Innovation Solution

A system combining binary analysis, in-situ record-and-replay, and debugging registers to automatically diagnose software failures by simulating programmer debugging procedures, providing precise fault propagation chains without excessive overhead or privacy issues.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If post-mortem analysis of core dumps is used, then partial sequential errors can be diagnosed, but concurrency failures cannot be diagnosed due to lack of interleaved accesses from multiple threads

Engineering Contradiction:

Improvefailure diagnosis capabilityVSAvoidability to diagnose different failure types

Core Design Contradiction:

Measurement precisionVSAdaptability or versatility

Solution Approach 1:

The system creates a copy of the execution state by recording program counters, register values, and memory states during original execution, then replays these recorded states to reconstruct and analyze concurrency failures without needing access to the actual production environment

Inventive Principle:

Principle #26Copying

Solution Approach 2:

The system performs preliminary recording of execution information during normal program operation, storing program counters, register values, and memory states before failures occur, enabling subsequent offline replay and analysis of both sequential and concurrency failures

Inventive Principle:

Principle #10Preliminary action

2Measurement precision

If record-and-replay systems are used to replay failures offline, then failure analysis can be performed, but prohibitively high performance overhead is imposed

Engineering Contradiction:

Improvefailure analysis capabilityVSAvoidperformance overhead

Core Design Contradiction:

Measurement precisionVSProductivity

Solution Approach 1:

The system extracts only the essential execution information needed for failure analysis (program counters, register values, memory states) rather than recording complete execution traces, reducing the overhead of the record-and-replay mechanism while maintaining diagnostic capability

Inventive Principle:

Principle #2Taking out (Extraction)

Solution Approach 2:

The system records partial execution information selectively at relevant points during program execution, focusing on capturing states necessary for failure diagnosis without comprehensively tracking all execution details, thereby reducing performance overhead

Inventive Principle:

Principle #16Partial or excessive action

3Measurement precision

If conventional record-and-replay systems are used, then offline failure replay can be performed, but the same runtime environment is required which may not be accessible due to privacy reasons

Engineering Contradiction:

Improvefailure replay accuracyVSAvoidaccessibility to runtime environment

Core Design Contradiction:

Measurement precisionVSEase of operation

Solution Approach 1:

The system copies essential runtime state information (program counters, register values, memory states) into recordable data structures that can be stored and replayed without requiring access to the original production runtime environment, preserving privacy while enabling failure analysis

Inventive Principle:

Principle #26Copying

Solution Approach 2:

The system introduces an intermediary recording layer that captures execution states and stores them in a privacy-preserving format, allowing offline replay and analysis without direct access to the confidential production environment or sensitive data

Inventive Principle:

Principle #24Intermediary (Mediator)

4Adaptability or versatility

If multiple successful and failed traces are recorded to statistically infer control flow differences, then concurrency failures can be analyzed, but the system is not designed to diagnose sequential failures or failures caused by multiple variables

Engineering Contradiction:

Improveconcurrency failure analysisVSAvoidsystem design complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system implements a universal failure analysis framework that can diagnose both sequential and concurrency failures, as well as failures caused by single or multiple variables, using the same recording and replay infrastructure without requiring separate specialized systems

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS11599445B2Watcher: precise and fully-automatic on-site failure diagnosis

Publication Date: 2023.03.07 BOARD OF RGT THE UNIV OF TEXAS SYST

AI summary

The techniques described herein may provide techniques for precise and fully-automatic on-site software failure diagnosis that overcomes issues of existing systems and general challenges of in-production software failure diagnosis. Embodiments of the present systems and methods may provide a tool capable of automatically pinpointing a fault propagation chain of program failures, with explicit symptoms. The combination of binary analysis, in-situ/identical replay, and debugging registers may be used together to simulate the debugging procedures of a programmer automatically. Overhead, privacy, transparency, convenience, and completeness challenges of in-production failure analysis are improved, making it suitable for deployment uses.