Browse Prior Art Database

A method to customize debugging trace path by adding breakpoint priority definition and program flow control mechanism

IP.com Disclosure Number: IPCOM000173655D
Original Publication Date: 2008-Aug-20
Included in the Prior Art Database: 2008-Aug-20
Document File: 4 page(s) / 46K

Publishing Venue

IBM

Abstract

A method to customize debugging trace path by adding breakpoint priority definition and program flow control mechanism

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 4

A method to customize debugging trace path by adding breakpoint priority definition and program flow control mechanism

1. Background: What is the problem solved by your invention? Describe known solutions to this problem (if any). What are the drawbacks of such known solutions, or why is an additional solution required? Cite any relevant technical documents or references.

Current debugger, including gdb,

jdb, ms vc debugger, and so on, have not a better executing flow

control on the debugging point. Below is an example:

Look at above screen shot, you want to debug this program, then set two breakpoints, breakpoint 1 and breakpoint 2. The debug path you want is breakpoint 2->breakpoint 1. But when you start the program, it will stop at breakpoint 1 first, because OtherFunction()

will call CommonFunction() before

MyFunction() calls CommonFunction() and even worse if there are many OtherFunction(), CommonFunction()

will be called so many times, that the program will be always stopped at

breakpoint 1. You don't know when the program will go to breakpoint 2. In this case,

is to set breakpoint 1 to be unchecked. Then start the program, it will stop at breakpoint 2. Then check breakpoint 1. Though there are the condition breakpoint and hit counts that can help us to get the right break sequence. But under some complicated case, there are difficult to use. So, We really need a better way that we can tell the debugger the required correct break sequence.

Actually debugging real programs are more worse than the above example, because real programs are more bigger and more complex. Take Lotus Notes/Domino as an example, Notes/Domino is a huge program, the total numbers of code line is at 10 million level. So debugging Notes/Domino codes is a terrible thing. To fix a bug, you have to set many breakpoints at many files.There are innumerable message loop in the codes, so you are always trapped in the loop. Debugging other real big programs also have the same problem.

Current debugger cannot define the execution flow control on our defined breakpoint and also can not store the debugging information which we developers really need in below cases:

1

what you can do

[This page contains 1 picture or other non-text object]

Page 2 of 4

1.

When we want to control the action sequence of many break points, there are no better way to do

it.

When you share your debug environment to other colleagues, they will get confused by the mess

breakpoints, because they cannot get a valid debug path only from the breakpoints.

When a long time pass, you want to see how you debug one problem, you will be trapped in the

breakpoints, because it hard to remember the debug path you found before.

Below is some known solutions which can partly resolve the problem.
condition breakpoint. You can give some simple conditions to breakpoints. These conditions can...