Browse Prior Art Database

A way of making debugging easier by tracing variable forming

IP.com Disclosure Number: IPCOM000241325D
Publication Date: 2015-Apr-17
Document File: 8 page(s) / 185K

Publishing Venue

The IP.com Prior Art Database

Abstract

As the developers are facing the debug issues in their daily life, especially for the variable forming process in runtime environment, seems it is the most important part in debuging phase which can tremendously increase the debuging performance. this disclosure aiming to describe a new way of generating the variable setup tree structure to clearly illustrate the variable forming processing for developers in order to fast locating the issue.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Page 01 of 8

A way of making debugging easier by tracing variable forming

In most cases of program debugging, it turns out that the error happens is because the value of the variable is not as expected, such kind of errors we often encountered are, null pointer exception, data type not compatible that making assignment failed, and the right-hand value not fall in the expected range that fails the corresponding check etc. So to know how the value to be assigned to the variable is formed and as early as possible to locate where the original value is wrong helps a logs in making debugging easier, unfortunately current debugging tools focus on providing information stack by stack according to the calling order, to solve such type of error, the developer have to check the data step by step by traversing the calling stack, it is quite time consuming and can easily get lost with its working context.

Innovation idea
In general, the idea we proposed to solve the above problems is, constructing a tree structure in which all the data contributing to forming the variable will be kept there, in the debugging environment by spreading this tree which might be a icon over the variable developer can easily have a view of what is the reason that leads to the problem.

Take one jenkins problem as an example, as shown below, to fix the exception of !java.io.FileNotFoundException% in accessing folder !/var/lib/jenkins/builds/BlueMixTest/builds/3%, in the debugging environment developer have to step by step go through the calling stacks to figure out how the string !/var/lib/jenkins/builds/BlueMixTest/builds/3% was formed,

1


Page 02 of 8

2


Page 03 of 8

corresponding with the above method calling stack, to infer the variable forming relation, probably the following sources codes have to be checked step by step as detailed by below:

1

/*package*/staticlongparseTimestampFromBuildDir(File buildDir) throwsIOException, InvalidDirectoryNameException{

try{

if(Util.isSymlink(buildDir)) { 2

protected AbstractBuild(P project, File buildDir) throwsIOException {

super(project, buildDir);

}

3

protectedBuild(P project, File buildDir) throwsIOException {

super(project,buildDir);

}

4


publicFreeStyleBuild(FreeStyleProject project, File buildDir) throwsIOException {

3


Page 04 of 8

super(project, buildDir);

5, 6, 7, 8

Method without souce code

9


protectedR loadBuild(File dir) throwsIOException {

try{

returngetBuildClass().getConstructor(getClass(),File.class).newInstance(this,dir);

10

protectedR loadBuild(File dir) throwsIOException {

try{

         returngetBuildClass().getConstructor(getClass(),File.class).newInstance(this,dir); 11

12

privateRunMap

createBuildRunMap() {

returnnewRunMap

(getBuildDir(), newConstructor

() {

publicR create(File dir) throwsIOException {

returnloadBuild(dir);

}

});

} 13 privateRunMap

createBuildRunMap() {

returnnewRunMap

(getBuildDir(), newConstructor

() {

publicR create(File dir) throwsIOException {

returnloadBuild(dir);

}

});

}

... 17 protectedsynchronizedR load...