PDA

View Full Version : The end of an Era



abachler
11-06-2007, 10:21 AM
Woe is me, for the first time today I actually encountered a problem with some code for which I had to result to running the debugger. After 28 years of programming without once resorting to the debugger, I now hang my head in shame :cry:

On the up side I like the 2005 debugger better than 6.0

Prelude
11-06-2007, 10:43 AM
>After 28 years of programming without once resorting to the debugger
...you finally started writing something non-trivial? ;)

indigo0086
11-06-2007, 11:08 AM
...you finally started writing something non-trivial? ;)

Roomba's aren't going to program themselves

brewbuck
11-06-2007, 11:29 AM
Woe is me, for the first time today I actually encountered a problem with some code for which I had to result to running the debugger. After 28 years of programming without once resorting to the debugger, I now hang my head in shame :cry:

If I can't spot a problem within 10 minutes by inspection I usually just go straight to the debugger. Adding print statements is a much slower cycle because the code takes about 3 minutes to link. 3 minute turnaround just to add some debug prints sucks.

If I was working with a smaller, nimbler codebase I'd probably just use print statements for a lot of things.

Debugger hardware watchpoints are great for playing the "Who the hell changed the value in this variable" game.

laserlight
11-06-2007, 11:34 AM
Does anyone follow the "test first" principle of extreme programming? It seems to me that such an approach would rarely require the use of a debugger since the currently failing test would immediately show the source the problem.

brewbuck
11-06-2007, 11:37 AM
Does anyone follow the "test first" principle of extreme programming? It seems to me that such an approach would rarely require the use of a debugger since the currently failing test would immediately show the source the problem.

That would be true if testing was guaranteed to find all errors. Then, you could actually assume that if Build 10 is good, and Build 11 is bad, then an error was introduced somewhere between Build 10 and Build 11.

In reality, the error may have been introduced back in Build 8, was not uncovered during testing, and now some benign change between Build 10 and Build 11 has caused it to "wake up."

Continual testing is, of course, a given. But passing tests doesn't prove you have a working product :)

Daved
11-06-2007, 12:32 PM
>> After 28 years of programming without once resorting to the debugger
Wow, I almost never run my program except through the debugger. How long do you take to find the causes of bugs if you do it by looking at code?

twomers
11-06-2007, 12:44 PM
>> On the up side I like the 2005 debugger better than 6.0
Er... when did you use the other one? LIAR!
I have yet to use it... though I think it's a-la Prelude's response.

>> How long do you take to find the causes of bugs if you do it by looking at code?
I generally don't program bugs into my code :)

laserlight
11-06-2007, 12:51 PM
That would be true if testing was guaranteed to find all errors. Then, you could actually assume that if Build 10 is good, and Build 11 is bad, then an error was introduced somewhere between Build 10 and Build 11.

In reality, the error may have been introduced back in Build 8, was not uncovered during testing, and now some benign change between Build 10 and Build 11 has caused it to "wake up."
Ah, that makes sense.


I generally don't program bugs into my code
I have seen this quote attributed to Dijkstra: "If debugging is the process of removing bugs, then programming must be the process of putting them in."

Daved
11-06-2007, 12:55 PM
>> I generally don't program bugs into my code

I take pride in the fact that my code only generates a hundred or so bugs per feature. I don't think it's humanly possible to code in our app without creating one.

brewbuck
11-06-2007, 01:00 PM
Wow, I almost never run my program except through the debugger. How long do you take to find the causes of bugs if you do it by looking at code?

I find that sometimes, using a debugger seems to make my brain shut off. I've wasted hours tracing through code where I SWORE the problem was, only to find the error just by stepping back and spending 15 seconds actually thinking about it.

The other technique I use is to speak to the photograph of my son which sits on my desk. I try to explain the problem to him. Usually when I do this the solution occurs to me. Thanks little guy!

Daved
11-06-2007, 01:04 PM
My kid has a look on her face that says, "Seriously? You're seriously looking at me for help? Have you seen that code? Good luck buddy." Needless to say that doesn't help.

twomers
11-06-2007, 01:25 PM
God, nobody has a sense of humour anymore. Sure I've programmed bugs into my code. But nothing that needed going to the debugger.

>> my code only generates a hundred or so bugs per feature
That's going in my signature. You mind? I understand what you mean, of course, but taken out of context that is very funny!

I have no kids. Most of my bugs are from me not thinking about something right.

Daved
11-06-2007, 01:31 PM
>> God, nobody has a sense of humour anymore.
I think everybody understands you weren't being serious. Either that or you really work on some trivial programs, like write a program that maybe compiles and maybe doesn't, but doesn't do anything. It'd be hard to unintentionally create a bug for that one.

>> That's going in my signature. You mind?
You should use the whole line. I take pride in that fact. We're currently on bug #13000, and we reset to 1 several years ago.

twomers
11-06-2007, 01:44 PM
>> You should use the whole line.
There is that. Links to the quote though. I'm kinda going for people reading it out of context. Not running a program is a good way not to have any bugs alright.

>> I think everybody understands you weren't being serious.
Yeah. I know. But no acknowledgment? What kind of world is this?

Daved
11-06-2007, 01:49 PM
Maybe it is better to use the shorter version. Don't link to the quote, though... that ruins the effect.

twomers
11-06-2007, 01:53 PM
Yes sir. Sorry sir.

Thantos
11-06-2007, 03:27 PM
For one project I'm involved with we have one developer who is in charge of producing bugs.

I generally use the debugger when it works with printf but crashes without printf. Oh those are the fun bugs :D

abachler
11-06-2007, 03:51 PM
Continual testing is, of course, a given. But passing tests doesn't prove you have a working product :)

Well, the code I write tends to either work perfectly or fail in a spectacular manner. My general debuggin technique is to look at the code, then add some Beep()'s in to see where it is running and where it craps out. Of course theres always the comment everything out until it stops crashing method. I generally use incremental build and auto-precompiled headers, so I usually only have to recompile the one file im in and then relink, takes maybe 10 seconds. Now if I have to recompile all 100,000 lines of code it takes like 2 minutes, which gets annoying. The fact I never use the debugger, and in fact rarely even compile the debug version drives my boss nuts, but most of the bugs I have to find arent ones that will show up in the debugger anyway.

brewbuck
11-06-2007, 04:13 PM
I generally use incremental build and auto-precompiled headers, so I usually only have to recompile the one file im in and then relink, takes maybe 10 seconds.

It's not the compile step that takes forever for me. Our build system manages that correctly. If only one file has changed, only one file gets recompiled.

The linking step itself takes several minutes. JUST TO LINK. This is due to a poor choice of algorithm inside the GNU linker that scales terribly when you use many, many archive libraries. And yes, I've profiled it, traced it down, and proven it. If you are linking across an NFS share things get almost 3x worse. And of course, our product consists of 25 or 30 libraries, so the problem is greatly amplified.

I actually tried creating a customized linker tool which merged ELF objects into larger and larger archives to feed into the linker -- it links much faster that way. The resulting tool was brittle and I never trusted the code it produced, so I stopped using it. Now I just put up with the stupidly slow link time.

On other systems, where the linker is not GNU, the product links in seconds.

Daved
11-06-2007, 04:22 PM
I don't understand how writing to cout or printf or adding beeps can be easier than running through the debugger, especially if you're using the VC++ debugger. I guess if it works for you, fine, but maybe a few weeks getting used to all the bells and whistles (no pun intended) available could make you even more productive.

abachler
11-06-2007, 04:36 PM
Well, as I said, most of the undocumented features in ym programs arent the kind that will crash the app, they just cause it to display interesting behavior. Even the app crashing bugs are usually easy enough to track down, 99% of them are a bad pointer. In fact the one that made me use the debugger was a bad pointer, but the source was convoluted. I was randomizing the sequence of an array of pointers and somehow a NULL was creeping in even though it 'shouldnt'. Ultimately the whole thing was resolved with a check for NULL prior to executing a function that took the pointer as an argument. I am using a pointer to an array of pointers, so 6.0 just showed me the value of the base pointer, while 2005 showed me the contents of the array ( which is why I can say I like 2005 better than 6.0 without lying about having never needed to use either one before).

twomers
11-06-2007, 04:36 PM
>> I don't understand how writing to cout or printf or adding beeps can be easier than running through the debugger,
I'm afraid of my debugger -- never used it. It could be complicated and I could fail at. It's an insecurity thing really.

Thantos
11-06-2007, 04:43 PM
I don't understand how writing to cout or printf or adding beeps can be easier than running through the debugger, especially if you're using the VC++ debugger. I guess if it works for you, fine, but maybe a few weeks getting used to all the bells and whistles (no pun intended) available could make you even more productive.

I've never found a debugger I liked. Never used VC++ and I won't use microsoft compilers anymore (bad incident with one a long time ago). In fact I hardly even use GUI frontends anymore. I have a good text editor and some good command line tools.

That and the output method is pretty universal so when I'm flipping between a bunch of languages I don't have to remember which debugger does what.

brewbuck
11-06-2007, 04:51 PM
I was randomizing the sequence of an array of pointers and somehow a NULL was creeping in even though it 'shouldnt'. Ultimately the whole thing was resolved with a check for NULL prior to executing a function that took the pointer as an argument.

NULL-protection is always good but aren't you concerned that the NULL shouldn't have been present to begin with?

Daved
11-06-2007, 04:53 PM
>> I'm afraid of my debugger -- never used it.
I would put the debugger at #1 on my list of favorite/most helpful development tools. I use it more than any other part of the IDE. The VC++ debugger is extremely powerful and makes my life so much easier. I use it even when looking at code of people who post questions here.

The simple parts are extremely helpful by themselves, including breakpoints, step over/step into/step out and the watch windows. More advanced stuff like modified breakpoints, the memory windows, set next statement and editing memory values as you go are great.

I don't even use the Edit and Continue feature, either, which if it works could be fantastic.

My list of best inventions ever goes something like this:

TiVo
The wheel
VC++ debugger
Tabbed browsing
Sliced bread

If you're already using VC++, learning the debugger is a no-brainer (unless of course you're completely happy with how you're doing things right now).


>> I've never found a debugger I liked.
I was never much of a fan of gdb when I used it long ago. There's a big difference between command line debuggers and a visual debugger. If you're not compiling with VC++, though, then it doesn't matter how good its debugger is. I don't know if there are any other visual debuggers for C++ that compare.

brewbuck
11-06-2007, 04:58 PM
I was never much of a fan of gdb when I used it long ago. There's a big difference between command line debuggers and a visual debugger. If you're not compiling with VC++, though, then it doesn't matter how good it's debugger is. I don't know if there are any other visual debuggers for C++ that compare.

gdb + emacs + cscope == super winning combo. All integrated in the same UI.

twomers
11-06-2007, 05:04 PM
Wait. I have used the debugger but I assure you it was an accident. Something to do with just-in-time debugging and an assumption that hitting return fast and hard would make it go away... Would it really be as fast as writing some printing statements and such, Daved? Might take a look at it the next time I'm coding something. It always seemed a bit overkill to me in my simple world to be honest. Aside from the features you mentioned which others would be worth playing with?

hk_mp5kpdw
11-06-2007, 05:11 PM
For one project I'm involved with we have one developer who is in charge of producing bugs.

I generally use the debugger when it works with printf but crashes without printf. Oh those are the fun bugs :D

I used to get those. The program wouldn't work so I'd put a couple printfs to debug. For whatever reason it would then work. Then I'd take out the printfs expecting the program to not work but it would still work and no other code had changed other than adding/commenting out those printfs. Yeah... fun indeed.

twomers
11-06-2007, 05:15 PM
>> (bad incident with one a long time ago)
Deaths?

Daved
11-06-2007, 05:20 PM
>> Would it really be as fast as writing some printing statements and such, Daved?
It's faster (at least for me).

If you've got a small app and you're already running through VC++, just hit F10 (step over) instead of Run (F5) or Execute (Ctrl-F5). Open and dock the Autos window (Debug > Windows > Autos). If your program has output and you have enough room on your monitor (two monitors helps) then put the console or other window next to the debugger, otherwise it will have to be hidden which isn't ideal for this simple exercise.

Then hit F10 to step over each line of code. When you get to a function you wrote, you can use F11 to step into it, then continue with F10. Watch the variables in the Autos window as they change. That's pretty much what the print statements are doing. The difference is you can see it for every line the first time, instead of adding a few statements and then narrowing down the location.

brewbuck
11-06-2007, 05:23 PM
Would it really be as fast as writing some printing statements and such, Daved? Might take a look at it the next time I'm coding something. It always seemed a bit overkill to me in my simple world to be honest. Aside from the features you mentioned which others would be worth playing with?

For one thing, a debugger will INSTANTLY pinpoint a segmentation fault. It doesn't necessarily explain WHY it happens, but it will give you a precise line number. I would hate to have to track down random segfaults by placing prints.

abachler
11-06-2007, 10:08 PM
NULL-protection is always good but aren't you concerned that the NULL shouldn't have been present to begin with?

I am, but its about number 50 on the list. Theres a trade show in vegas this weekend and we have to make a video of the app in action by then. I fixed most of the major issues, only have 3 features left to put in, and I have a small memory leak to track down. Dont think the debugger will help me with the leak unfortunately...

brewbuck
11-06-2007, 10:20 PM
I am, but its about number 50 on the list.

Prioritization. Word.

abachler
11-06-2007, 10:31 PM
haha, yeah but tell that to my boss. I had this annoying handle leak for like 4 months because he kept addign features and wouldnt let me take the time to fix it, turns out it only took a couple hours to fix, and its been making teh app crash after 30 minutes for the last 4 months.

zacs7
11-06-2007, 11:55 PM
>Theres a trade show in vegas this weekend and we have to make a video of the app in action by then.
Heard of photoshop? :)

> and its been making teh app crash after 30 minutes for the last 4 months.
That's easy to fix, introduce a 'feature' where the program restarts every 29 minutes :)

novacain
11-16-2007, 01:12 AM
I find the debugger a valuable tool. Can not imagine coding without using it.

I suppose I am just lazy....
I can read, analyse and plug in values to the code to work out what is wrong
or
I can run the code and the debugger will SHOW me what is wrong.



Aside from the features you mentioned which others would be worth playing with?


The ability to modify a variable during runtime, jump back and re-run the code, to test small sections of code over a range of values.
The trace statement (same as printf but to the IDE output window). Great for diagnosing real-time/network app issues.
Seeing non fatal exceptions reported as they occur (rather than where they cause a crash).
Edit and continue allows changes on the fly in big/time consuming operations.
Output shows memory not freed on close and gives address to help track it down (or immediate confimation that the leak is fixed / located in the commented out code).
Stack trace to find exceptions.

ect....

maxorator
11-16-2007, 08:18 AM
I debug my programs with OllyDbg lol...