Can anyone teach me how to debug a program?

[Israr Ahmad]

I want to know what kind of programs can be debugged and how to do this?

 

[DaveC426913]

That is an extremely broad question.

The short answers, in order, are:
- all of them and
- by myriad methods, depending on the language and tools available.

Perhaps you could refine your question a little.

Do you want to learn computer programming?
Do you have some source code that you want to fix?
Do you have a particular language in mind?

 

[Israr Ahmad]

That is an extremely broad question.

The short answers, in order, are:
- all of them and
- by myriad methods, depending on the language and tools available.

Perhaps you could refine your question a little.

Do you want to learn computer programming?
Do you have some source code that you want to fix?
Do you have a particular language in mind?

YES, I want to learn computer programming.

 

[DaveC426913]

YES, I want to learn computer programming.

What kind of software do you want to write? This will influence what language you choose, which will in turn influence what books you might buy to read.

 

[Israr Ahmad]

What kind of software do you want to write? This will influence what language you choose, which will in turn influence what books you might buy to read.

I want to learn C++.

 

[berkeman]

I want to know what kind of programs can be debugged and how to do this?

Welcome to the PF.

As Dave is gently pointing out, when you post here at the PF, it is best to give as much background and information as you can about your question.

For starters, read through this link at Wikipedia to see if it helps get you started with your question...

https://en.wikipedia.org/wiki/Debugging

 

[DaveC426913]

There are plenty of online tutorials. You would do well to search through them for an Intro to programming.
If you have not programmed before, c++ might be a bit of a learning curve. You might start with BASIC.

I have found some courses from Udemy were worth the paltry price I paid for them.

 

[jedishrfu]

You could also start with Java, Python or JavaScript. All three are available in the Processing environment as installable modes each with a collection of examples and libraries to do some amazing stuff.

Check out the PF Insights page for The Joy of Processing to learn more.

Learning Java or Python wouldn't be a waste of time since they are somewhat derived from C just like C++. The basic difference between Java and C++ is in class inheritance where C++ allows for multiple parents whereas Java limits it to one but multiple inheritance is seldom used.

 

[phinds]

The basic difference between Java and C++ is in class inheritance where C++ allows for multiple parents whereas Java limits it to one but multiple inheritance is seldom used.

Well, yeah, if you're using the OOP characteristics of C++ but I've always thought that the BASIC difference between C++ and JAVA is that in JAVA you have no choice about whether you are using OOP whereas in C++ that is not enforced. Code can be written in "C++" that really is just C code. You can't do that in JAVA.

 

[jedishrfu]

Well, yeah, if you're using the OOP characteristics of C++ but I've always thought that the BASIC difference between C++ and JAVA is that in JAVA you have no choice about whether you are using OOP whereas in C++ that is not enforced. Code can be written in "C++" that really is just C code. You can't do that in JAVA.

True, but how many differences do I need to say in order to cover all of them?

To me the biggest difference was the issue of multiple inheritance that many programmers felt was great in theory but bad in practice. We used to practice single inheritance with mixins in our designs. Mixins were classes that added some specific feature to child clas but wouldn't confuse the inheritance tree.

 

[jedishrfu]

With respect to debugging, any program can be debugged sometimes via a tool that allows you to step through program execution, other times only via print statements.

In some cases, you might be really constrained as in an embedded system with no display or keyboard and would need to develop something special to help you debug like logging results to a file and reading it by text editor or something.

I had to do that once with a small microcomputer with toggle switches and led imdicators. It was very time consuming and somewhat painful as you had no idea why the program failed and you had to scrutinize your code for possible causes.

 

[ChrisVer]

It's better to ask the poster:
Do you know what a bug is?
I guess if you did you wouldn't ask when you need to debug...

when your program produces unexpected results or does not compile, then (99.99% of the times) there's a bug in your code: something is wrong in your code and you got to fix it. Fixing those is called debugging.
One very simple example is the following, which is a function that returns you the square of a number:

#include<iostream>

int square( double x){
   //returns square of number x
   return x*x;
}
int main(){
   double sqx = square( 2.0 );
   std::count<< sqx << std::endl;
   return 0;
}

your code will compile, you can run several tests with it, trying the square of 2,3,4,5 and see that the code is doing a perfect job in printing the squares of those numbers... all good until someone cranky chose to check the square of 0.4 believing he would get 0.16 back... you can try it and see that your code will fail producing the expected result... the problem is in the code and in particular the type definition of the function square, which casts the result to that of type int , so the resulted double 0.16 will try to be translated (casted) into an integer, which is 0 (your output)...
Going and replacing the int square with double square is 1 extremely simple example of debugging your code.

There are other cases which can scale in difficulty depending on the readability of the code up to its complexity... Making your code modular can help in some extent the debugging process, because it can be clear (most of the times) where you have to go and check for bugs...

That's some basic input from me.

 

[onoturtle]

This topic is interesting since I feel like I've just been winging it when it comes to debugging. Probably why every complex program I've worked has a billion bug tickets. Things I do...

- Reproduction: Ideally you can reproduce the bug. Can be tricky if the bug is intermittent (like say a race condition). If you can't trigger the bug at all, you might be able to deduce what went wrong if you had logs (see below) when the bug occurred and read the corresponding code.

- Read code: If the program is simple, then you might be able to deduce where in the code the error occurs just from the bug description, then you can go straight to reading that segment of the code and fix it if the issue is identified.

- Logging: Having your program write information about what it is doing to a text file. It can be useful when say a customer reports a problem, as it allows you to see to some extent what was going on under the hood. Or it can be useless if you don't log the relevant information, but it hopefully informs you on what additional logging to add so that you have better luck the next time the bug occurs.

- Debugger: Only relevant if you can reproduce the bug. With a debugger program, for example, you can execute your code line-by-line and examine the contents of each variable, how they change, and hopefully you'll then recognize the step(s) that need to be adjusted to avoid the bug.

- Testing: After the fix is completed, make sure your suite of unit and regression tests still past. You don't want to fix one bug only to introduce 10 more with the fix. Obviously automated testing and testing from QA engineers doesn't prevent that because it is not practical to test all possible inputs (except for a trivial program), but it does provide some confidence (but not too much when your bug tracker is overflowing).

 

[newjerseyrunner]

All programs can be debugged. The reason that you can't simply throw any program on your computer into a debugger is because debugging requires extra stuff be put into the code so that the debugger can give you back useful information. This gets stripped out during release. This is why when you first create a project in almost any IDE, you have a Debug and Release build option by default.

 

[fluidistic]

In my case (beginner and self taught with lots of bad/wrong habits), I debug using :
0) Lots of print statements. I have to make sure what I Think the code is doing is really doing it.
1) Test programs. Sometimes when I'm unable to figure out where the bug(s) is, I try to create a minimal working example. I basically copy and paste (or try to recreate as closely as possible some part(s) of the original code) the original code into a new file where I can manipulate the code more easily than in the original code.

 

[DaveC426913]

0) Lots of print statements. I have to make sure what I Think the code is doing is really doing it.

I still do this. I'm old school. It actually cost me a potential job. Employer was not impressed to see me debugging using console.log (JavaScipt equivalent of Print)

The modern way is to use breakpoints and step through the code, to watch what is happening as it happens.

 

[Mark44]

I still do this. I'm old school. It actually cost me a potential job. Employer was not impressed to see me debugging using console.log (JavaScipt equivalent of Print)

Sometimes the equivalent of print is the only debugging tool available. About four years ago I was trying to write some code samples for SharePoint (a MSFT product), and my code was running against a SharePoint server running on a cloud OS, that would send back a stream of text to populate a web page. For quite a while I wasn't getting anything back, and couldn't figure out any way to set a breakpoint on the server. (There probably is a way, but a fair amount of study on my part didn't unearth it.) My solution was to insert output statements throughout my code, and determine what part of my code was working and where it stopped working by the output I got. Once I figured out where my output statements weren't being hit, I could focus my efforts there and figure out why. After a number of iterations using this process, I was able to get my code working correctly.

 

[newjerseyrunner]

I still do this. I'm old school. It actually cost me a potential job. Employer was not impressed to see me debugging using console.log (JavaScipt equivalent of Print)

The modern way is to use breakpoints and step through the code, to watch what is happening as it happens.

If it was solely because of that, the guy was an idiot anyway. I'm a professional programmer and I've worked with dozens of other great experts. Everybody does count, prints, var_dump...

For me, doing a bunch of variable dumps in real time allow me to intuit the problem far faster than setting breakpoints and stepping could ever.

 

[DrClaude]

I still do this. I'm old school. It actually cost me a potential job. Employer was not impressed to see me debugging using console.log (JavaScipt equivalent of Print)

The modern way is to use breakpoints and step through the code, to watch what is happening as it happens.

If it was solely because of that, the guy was an idiot anyway. I'm a professional programmer and I've worked with dozens of other great experts. Everybody does count, prints, var_dump...

For me, doing a bunch of variable dumps in real time allow me to intuit the problem far faster than setting breakpoints and stepping could ever.

Real programmers don't use debuggers

(For the youngings who don't understand the joke, see http://web.mit.edu/humor/Computers/real.programmers).

 

[ChrisVer]

The modern way is to use breakpoints and step through the code, to watch what is happening as it happens.

What would that mean in practice?

I agree with the others : you were lucky to avoid such an employer...

 

[Mark44]

The modern way is to use breakpoints and step through the code, to watch what is happening as it happens.

What would that mean in practice?

If you insert a breakpoint into your code, and run your code (in a debugger), the program will halt at the breakpoint. The debugger typically will have other windows/panes you can open to see the values of variables, memory, the stack, and many other facets of your program.
After hitting the breakpoint, you can singlestep through your program, one line of code at a time, to see which variables are changing, and their new values.

You (@ChrisVer) posted several questions on C++ programming recently. A debugger is an extremely valuable tool. Being able to use a debugger makes it much easier to find and fix bugs in your program. I've been teaching classes in C and C++ recently. By the time each class is over, the students are fairly proficient in using a debugger (at least the ones who pass).

 

[DaveC426913]

What would that mean in practice?

If you;'re doing web dev, your browser should allow you to open the JavaScript (or whatever) in the browser, and place breakpoints in it (a feature of the Developer tool). Then you serve up the page, and it will stop at the given line, allowing you to test the value of your vars at that moment. Other languages (such as C#) have other developer tools (such as Visual Studio), that allow the same kind of walk-through.

I agree with the others : you were lucky to avoid such an employer...

No, it wasn't just that. I sort of froze when it came to debugging while they were shoulder-surfing.

 

[ChrisVer]

If you insert a breakpoint into your code, and run your code (in a debugger), the program will halt at the breakpoint. The debugger typically will have other windows/panes you can open to see the values of variables, memory, the stack, and many other facets of your program.

hmm I guess I should start using some IDE... so far I have been working with codes using vi and text editors... I didn't have the chance to work with any kind of debugger efficiently...

 

[onoturtle]

GDB is a command-line debugger, if I recall correctly. I'm not sure if it can integrate with vi or vim, but I sort of remember emacs having such a feature. I know lots of web/Linux devs who primarily use vim (handy when doing dev on a live remote dev system, rather than editing locally and uploading each iteration), so I presume you can get a debugger in there. I don't personally know since I used emacs in school (and forgotten it all at this point) and have been using fancy GUI IDEs since, as I don't do web dev or work on a remote system much.

 

[Mark44]

hmm I guess I should start using some IDE... so far I have been working with codes using vi and text editors... I didn't have the chance to work with any kind of debugger efficiently...

Using an IDE is convenient, but you really should be using a debugger, some of which are standalone, not connected with an IDE. Anyone writing code these days who doesn't use a debugger is not working efficiently.

 

[jtbell]

(http://web.mit.edu/humor/Computers/real.programmers)

No, the Real Programmer wants a `you asked for it, you got it' text editor -- complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise.

I wrote my physics PhD dissertation with TECO, using RUNOFF commands for formatting the margins, etc.

(RUNOFF was a text-markup and formatting language, in a similar spirit as HTML.)

 

[JorisL]

The modern way is to use breakpoints and step through the code, to watch what is happening as it happens.

Unfortunately this doesn't always work. Today I was stumped why a "release version" crashed (vague exception too :().
I narrowed it down to one of two methods and set a breakpoint. It didn't work because I was communicating with some hardware that required an acknowledgment within a second or would retransmit. stepping through the code took longer :-(
Eventually I noticed my mistake when glancing at my Task list (TODO comments are great by the way). I hadn't implemented the final part of a small helper class which resulted in a NullReferenceException (which somehow got eaten by an unknown exception).

Logging got me through that problem. It's crazy how often I get lost in these great tools and fall back to extreme amounts of logging (Another time my (combined) logfiles for a single testrun of 30 seconds were several MB, which in the eventual code would fill up the HDD very fast as the code keeps getting started)

 

[newjerseyrunner]

Yes, breakpoints with parallel programming is less useful than it is with procedural. That's where I tend to start throwing printf() at the problem. Of course, often adding prints changing the timing of everything and hides the big you're trying to find. Thats when you pull out the big guns: valgrind.

 

[ChrisVer]

valgrind

is valgrind good for debugging? I thought it was for memory control... (so maybe for hunting seg faults?)

 

[newjerseyrunner]

is valgrind good for debugging? I thought it was for memory control... (so maybe for hunting seg faults?)

It's not a debugger in the same way that gdb is, but it's invaluable for hunting multi threading and weird memory bugs.