Do you use a debugger?

I use a debugger whenever I get a crash. There is no point wasting time pinpointing the crashing line of code, when the debugger can tell you instantly.

For "behavioral" bugs, I usually try to find the problem by inspection before resorting to the debugger. It's easy to get lost in irrelevant parts of the code, walking through the same spot over and over, blinded to the actual problem.

As for your refusal to use a debugger having something to do with your level of experience... I have to object to those comments. I learned much of what I know from three old-school C programmers each of whom has over 25 years experience. In the minds of all three, the tendency to jump immediately to the debugger is a sign of inexperience.

I am still making up my mind on the topic. I do use a debugger on a daily basis, but it is only a small part of the debugging process. The debugger, being a big, glittering, fancy tool, can blind you to the true nature of very simple problems sometimes.

Also, I have gained the habit of ALWAYS predicting the outcome of any change to the codebase before trying it. Be scientific. Just experimenting randomly and seeing what happens is undisciplined. The debugger can encourage this kind of shotgun approach. Try to think about it before resorting to the debugger.

Quote:

---

Originally Posted by Bubba

Try a half-million to a million or so lines of code. Then come back and say you don't use a debugger. If you don't I'm sure you are wasting valuable time. Only a fool refuses to use the tools that are at his/her disposal.

---

I work every day inside a 1.2 million line codebase and many problems do not require a debugger to solve, or simply can't be solved purely with the debugger. Knowledge of the codebase as a whole is necessary to avoid making "fixes" that are actually just stupid patches to localized problems, when what is actually being indicated is a higher level architectural issue.

The debugger is a tool, not a Tao.

Ahh crap... I lost :(

Quote:

---

Originally Posted by Bubba

Try a half-million to a million or so lines of code. Then come back and say you don't use a debugger. If you don't I'm sure you are wasting valuable time. Only a fool refuses to use the tools that are at his/her disposal.

Your question is very similar to this:

Do you use the accelerator in your car?

No I prefer to push my car all the way to work.

---

I think it's more of you don't need a sledgehammer to crack a nut.

Quote:

---

Originally Posted by brewbuck

Also, I have gained the habit of ALWAYS predicting the outcome of any change to the codebase before trying it. Be scientific. Just experimenting randomly and seeing what happens is undisciplined. The debugger can encourage this kind of shotgun approach. Try to think about it before resorting to the debugger.

---

Really?
I usually find that the debugger gives me an insight on the actual problem, giving me a better basis to make modifications from. Otherwise I would just have to guess and fiddle around to find the source of the error.

The debugger is a tool to help you better understand the flow of the code and finds bugs or find out why something happens as it does. Therefore I find myself relying on it quite often.

I find that trying to think about code and possible outcomes just wastes more time than it solves. All it does is take your debugger, step through the code, observe what happens, maybe change some variables here and there and the question is solved. It gives you further insight as well, and takes less time and less requiring than having to sit thinking and trying to analyze the code.

Of course, just relying on the debugger for everything is bad. You must know how the code will flow in a way so that you won't write poor code in the first place. The debugger cannot solve everything. A good design and proper error handling is something the debugger cannot solve and is something the programmer needs to create with some creative and proper thinking and analysis.
Often I come to the conclusions of what I must have when I find how something doesn't work with the help of the debugger. In this, the debugger aids me in solving the question of what is necessary for the actual implementation to work.

A great tool, all in all.

Quote:

---

Originally Posted by esbo

I think it's more of you don't need a sledgehammer to crack a nut.

---

I think you have it the wrong way around. The debugger is the nut cracker and your bare hands is what you're using to open the nut.
Don't make it too hard on yourself.

Quote:

---

Originally Posted by Elysia

Really?
I usually find that the debugger gives me an insight on the actual problem, giving me a better basis to make modifications from. Otherwise I would just have to guess and fiddle around to find the source of the error.

---

"Guessing" and "fiddling" isn't the only option. Another option is to look carefully at the code.

Quote:

---

The debugger is a tool to help you better understand the flow of the code and finds bugs or find out why something happens as it does. Therefore I find myself relying on it quite often.

---

Watching the code run is a good way to understand it, yes. I never said I don't use a debugger.

Quote:

---

I find that trying to think about code and possible outcomes just wastes more time than it solves.

---

So you'd rather just blast out a random change to make the problem go away without having the slightest clue what you just did?

"Hey, my check engine light turned on. I fixed the problem by cutting the wire. That sucker won't turn on any more, I guarantee it."

Quote:

---

I think you have it the wrong way around. The debugger is the nut cracker and your bare hands is what you're using to open the nut.
Don't make it too hard on yourself.

---

So how many millions of lines do you work with on a daily basis? I have a great example of my point from just this morning. I was trying to determine why performance had slowed by 3x between one version and a later version. Now, I have spent the last two months on sabbatical, so I had to spend several hours just swapping a lot of knowledge back into my head, that I had pushed aside during my time off. Yes, this involved a debugger.

I wasted the first half of the day watching code run. After lunch, I decided to actually look inside one of the output files. I saw a clue that immediately led me to the problem. It took all of about 5 minutes. If I'd stayed in the debugger I'm quite sure I would have wasted my entire day.

On the other hand, the debugger did help me to page a lot of essentially knowledge back in. I don't deny that the debugger can be tremendously useful. But I find the comments that the first response should always be to immediately jump into the debugger, and stay there, somewhat uninformed.

And if you want to know why code is performing poorly, a debugger-disassembler is also a great tool for studying correct programs. I had this code:

Code:

---

struct foo {
    int something;
    char the_buffer[1<<18];
    unsigned int a_index_for_the_buffer;
};

---

My program was working fine. But there was a 'bad thing' in it. The buffer index was below a big buffer. The generated assembly for the accesses of the buffer suffered a big drawback. The EBP register was used as the struct pointer, and index was way 256k after EBP. So every instruction for indexing the buffer was like: MOV [EBP+262148],EAX. Which included the literal 32bit number 262148 at the machine code of the instruction. Now the 686 family of processors has some hardcoded [EBP+-] certain offsets instructions which do not load a pointer offset.
If i hadn't used a disassembler to view my generated code, that would be an optimization i would have missed. I moved the buffer to the end of the struct, and code run 20-40% faster.

Quote:

---

Originally Posted by brewbuck

"Guessing" and "fiddling" isn't the only option. Another option is to look carefully at the code.

---

If I'd know what the problem was, I wouldn't use the debugger at all.
If it doesn't run as it should, then I usually use the debugger to observe the behavior more in detail so I can figure out WTF is going on.
And that means looking carefully at the code to see what I did wrong and so how to fix it.
It takes way longer just scanning over the code over and over instead of just using the debugger to find out where the wrong went.

Quote:

---

So you'd rather just blast out a random change to make the problem go away without having the slightest clue what you just did?

"Hey, my check engine light turned on. I fixed the problem by cutting the wire. That sucker won't turn on any more, I guarantee it."

---

Of course not.
When I change something, I know what I'm changing, and so by observing the outcome, I can understand what happened and from that I can draw a conclusion as to how it worked out that way.

Quote:

---

So how many millions of lines do you work with on a daily basis? I have a great example of my point from just this morning. I was trying to determine why performance had slowed by 3x between one version and a later version. Now, I have spent the last two months on sabbatical, so I had to spend several hours just swapping a lot of knowledge back into my head, that I had pushed aside during my time off. Yes, this involved a debugger.

I wasted the first half of the day watching code run. After lunch, I decided to actually look inside one of the output files. I saw a clue that immediately led me to the problem. It took all of about 5 minutes. If I'd stayed in the debugger I'm quite sure I would have wasted my entire day.

On the other hand, the debugger did help me to page a lot of essentially knowledge back in. I don't deny that the debugger can be tremendously useful. But I find the comments that the first response should always be to immediately jump into the debugger, and stay there, somewhat uninformed.

---

Performance issues is the work of a profiler. Unless, of course, you cannot determine the cause yourself. Instead of scanning over the code, all it took was one profiler run to determine the bottleneck and optimize it.

Avoiding the debugger usually just makes it take more time than without. The important thing is to know what you're doing and what is happening. Not just go around changing random code.

I find myself looking at the assembly output quite a bit sometimes, as well. It gives even further insights than reading the code could ever do.

EDIT: This whole post is a huge rant. Sorry for inflicting that on everyone. I'm killing it and taking a break.

Quote:

---

I work every day inside a 1.2 million line codebase and many problems do not require a debugger to solve

---

True not all problems surface by using a debugger. It isn't a magic wand but it does help greatly when you are adding new code to an existing code base. It really helps pinpoint possible side effects your code may have introduced. It doesn't tell you where the problem is but when you see something in the running code that triggers an 'aha' or 'wtf' (:D) you can set breakpoints and begin to diagnose the issue.

To me it's not a debate. I use the debugger a lot and combined with an increasing familiarity and knowledge of the existing code base it has been a tremendous help. You should be familiar with the code base you are working in. I will not disagree there at all. I fail to see how that really pertains to the discussion of debuggers but it is a good point.

Quote:

---

Originally Posted by Elysia

I'm sure, but I usually do tend to hear the opinions of the accused since they can give the most accurate answer from their point of view as to why a debugger is so horrible and irrelevant.
I think the question of the thread is not "do you use a debugger," but instead becomes "do you not use a debugger"?
And while we're at it, why not make the thread into a poll, so we can how many who do not use a debugger!? Wouldn't that be awesome?!

---

A poll is a very good idea. It's possible we've had one in the past, but I don't remember one.

As to why I don't use a debugger, see zacs7's post. ;) But to be honest, I'm not sure I could explain why. But having said that, it's really a matter of preference, just like coding style. I once read a thread on this subject in one of the newsgroups, and I was surprised by some of the programmers who said they rarely use a debugger. (The thread actually began as another topic).

I do understand both sides of the debate, and agree with those in this thread who say a debugger is a useful tool.

Just wondering, besides observing the program's behaviour, eyeballing the code and using a debugger, do you guys use tools like strace and dtrace?

Quote:

---

I was surprised by some of the programmers who said they rarely use a debugger.

---

I rarely use a debugger, but that's because I am a student who rarely works on projects that are anything other than small and simple. In such cases it is easier to find the problem by eyeballing and observing output, or if necessary, trimming the code to find the smallest and simplest program that demonstrates the error. Things like unit tests means even less need to use a debugger.

>> do you guys use tools like strace and dtrace?

I don't think I've worked on anything that requires these tools. Had I needed one I probably would have looked around to find something, but I don't know what they do. No.

Ah, I figured it was a case of me being lucky. Windows isn't this helpful.

I use a debugger quite often, as well as Valgrind for detecting memory errors. It's very useful.

strace? No, though I know of it. dtrace? Never heard of it. So, no. :)

Quote:

---

Originally Posted by laserlight

Just wondering, besides observing the program's behaviour, eyeballing the code and using a debugger, do you guys use tools like strace and dtrace?

---

I use the debugger fairly regularly, and sometimes have need to take a peek at a trace it provides. One of my favorite debugging tools is an oscilloscope. I used to also use PC-lint more, its static analysis capabilities are primo in addition to the rest of its usual duties. Whatever works to make code better.