Conditional Breakpoint on Call Stack During Debugging

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Developers face challenges in efficiently diagnosing issues in software code due to limited time for testing and the frequent triggering of simple breakpoints, necessitating improved tools for proactive problem identification.

Innovation Solution

A method and system for debugging executables that involve receiving breakpoints related to call stacks, executing the executable in a debug environment, and halting execution upon detection of a breakpoint, with an analysis tool gathering relevant information to aid in diagnosing issues.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If a simple breakpoint is set at a line of code, then the breakpoint can be easily detected, but it results in the breakpoint being hit more frequently than desired

Engineering Contradiction:
Improvebreakpoint settingVSAvoiddebugging time
Core Design Contradiction:
Ease of operationVSLoss of time

Solution Approach 1:

The patent applies parameter changes by transforming a simple breakpoint into a conditional breakpoint that includes additional parameters (call stack conditions, function names, line numbers). This allows the breakpoint to remain easy to set while adding filtering conditions that prevent it from being hit unnecessarily, thus resolving the contradiction between ease of operation and time loss.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The patent implements preliminary action by pre-defining call stack conditions and attributes before the breakpoint is encountered during execution. The system analyzes the call stack in advance and only triggers the breakpoint when the conditions are met, preventing unnecessary breakpoint hits before they occur and reducing debugging time.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If a breakpoint is set to catch all occurrences, then no issues are missed, but the diagnostic process becomes less efficient

Engineering Contradiction:
Improveissue detectionVSAvoiddiagnostic speed
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent applies local quality by making breakpoint conditions specific to particular call stack contexts rather than applying a uniform breakpoint to all occurrences. By analyzing the call stack structure and setting conditions based on specific functions, line numbers, and caller relationships, the system ensures reliable issue detection only where needed, maintaining productivity by avoiding unnecessary stops at irrelevant locations.

Inventive Principle:
Principle #3Local quality

3Productivity

If conditional breakpoints are used to skip unwanted breakpoints, then debugging efficiency improves, but the complexity of setting and managing breakpoints increases

Engineering Contradiction:
Improvedebugging efficiencyVSAvoidbreakpoint management
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent implements self-service by enabling the breakpoint system to automatically analyze call stacks and evaluate conditions without requiring manual configuration of complex filtering rules. The system service automatically determines whether to hit or skip a breakpoint based on the predefined call stack attributes, improving debugging efficiency while minimizing the complexity burden on the user.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS10162731B2Conditional breakpoint on call stack during debugging at runtime
Publication Date: 2018.12.25 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US10162731B2 patent drawing
  • US10162731B2 patent drawing
  • US10162731B2 patent drawing

AI summary

A method for debugging and executable is disclosed herein. The method begins by receiving one or more breakpoints defining one or more attributes of a call stack in the executable. The processor receives the executable in a debug environment. The processor executes the executable in the debug environment. The processor halts execution of the executable upon detection of a breakpoint contained in the executable.