|
This thread is locked; no one can reply to it. |
1
2
|
Randomly changing variable |
nonnus29
Member #2,606
August 2002
|
I never use debuggers either, just use printf or system.out.println, or whatever. But this article made me realize that being proficient using debugging tools can give you much powerful programming mojo: |
spellcaster
Member #1,493
September 2001
|
Quote: Well, depending on the amount of code between when you set it to non-zero and when it gets mysteriously reset to 0, you could always do something like this to try and spot where exactly it changes:
Geez! Writing to a log is nice to get a log. It's not a good debugging method. Use it to realize that there is an error, don't use it to hunt it down. Quote: I never use debuggers either, just use printf or system.out.println, or whatever. Using a debugger saves you a lot of time. if you consider yourself a coder, learn how to use a debugger. The 2 hours spent learning the basics of gdb (or the 0.5hours if you're using a debugger with a modern frontend) will be nothing in comparison to the time saved looking for a bug. Learn to use your tools. For a c/c++ coder these tools are: -- |
CGamesPlay
Member #2,559
July 2002
|
Without Valgrind, mine and BAF's TINS '07 entry would never have been submitted. It's just that good. -- Ryan Patterson - <http://cgamesplay.com/> |
james_lohr
Member #1,947
February 2002
|
A debugger is to programming as God-mode is to gaming. Quote: the 2 hours spent learning the basics of gdb Dev-C++ comes with gdb all ready to go. You just have to click a few buttons in the IDE. Still, I prefer only to enable God-mode when absolutely necessary
|
Richard Phipps
Member #1,632
November 2001
|
MSVC's debugger is handy, it useful catches some bound errors and uninitialised variables. The only problem I've found is that it really slows down when doing even a few new objects using a STL list container. |
spellcaster
Member #1,493
September 2001
|
Quote: A debugger is to programming as God-mode is to gaming. In that case I recommend that you code using copy con. Those fancy editors are pretty close to cheating either, eh? I hope you meant this as a joke. If not, I hope you don't consider a job where you have to code or interact with coders. -- |
Paul whoknows
Member #5,081
September 2004
|
Quote: A debugger is to programming as God-mode is to gaming. I rarely use debuggers, I use logfiles and I watch all the important variables using text_printf_ex instead. Is something wrong with me? ____ "The unlimited potential has been replaced by the concrete reality of what I programmed today." - Jordan Mechner. |
CGamesPlay
Member #2,559
July 2002
|
Quote: Is something wrong with me? Not until you start working on large projects. Seriously, after a few days wasted debugging like that you will invest the time to learn a debugger. -- Ryan Patterson - <http://cgamesplay.com/> |
Paul whoknows
Member #5,081
September 2004
|
Ok, I'll start right now. ____ "The unlimited potential has been replaced by the concrete reality of what I programmed today." - Jordan Mechner. |
james_lohr
Member #1,947
February 2002
|
Quote: I hope you meant this as a joke. If not, I hope you don't consider a job where you have to code or interact with coders. Of course I was only teasing. There are plenty of things you simply can't identify without a debugger, no matter how badly you pollute your code with log messages.
|
Myrdos
Member #1,772
December 2001
|
I first started using gdb to quickly debug crashes: 1) Compile your code with the -ggdb option 2) Use "gdb myprogram.exe" to debug it 3) Use the gdb "run" command to start your program. You can enter any command line arguments here. "run -res 640x480" 4) Use the "backtrace" command to figure out where the crash occurred. This will tell you the line number of the crash, where this function was called from, and where the calling function was called from, and so on all the way to your main program. There are plenty of other options that you can find using the "help" command, but these simple steps have alone have saved me countless hours of time. I find that no bug can withstand the combined might of good coding style and gdb. __________________________________________________ |
Jakub Wasilewski
Member #3,653
June 2003
|
Quote: There are plenty of other options that you can find using the help command, but these simple steps have alone have saved me countless hours of time. After learning to use that, the next step should be learning how to use bt (backtrace), up, down and print together. After learning those, you'll be able to nail 99% of all bugs in no time. For your problem, all you have to do is type 'tbreak <filename>:<linenumber>', with filename:line set to somewhere where the variable that is randomly changing is in scope - this will make the program stop once when it reaches that point. Run the program until it stops. Then, type 'watch <name_of_the_variable>' and the program will stop whenever the value gets changed. You can use 'cont' to continue if it's not the overwrite you were looking for (that is, it's happening inside the Set() method, which you can check with the 'bt' command). --------------------------- |
nonnus29
Member #2,606
August 2002
|
Here's a tute, I have a wierd little bug in my compiler/parser to practice on too...
|
23yrold3yrold
Member #1,134
March 2001
|
Quote: Are you using any sort of multi-threading? No. It's a little difficult to rip it apart though; lots of classes that talk to each other and make isolating large chunks of code impractical. Quote: Dev-C++ comes with gdb all ready to go. And that's the only nice thing you'll ever see me say about it. And yes, like I said it's to my shame I never really learned a debugger. I did try GDB a long time ago but never really got it working well. I still think this bug will just go away once the code's all cleaned up, but nonnus posted a nice looking link; guess I owe it to myself to read up. Or maybe look into Fortify. Shame there isn't a site like the GotW for debuggers. Here's some source code for a simple program, here's a weird bug in the program, find the bug and fix it. Little exercises like that for noobs like me. -- |
BAF
Member #2,981
December 2002
|
I had to hack at Fortify to get it to even compile under mingw. After I did, though, it worked well. |
Edgar Reynaldo
Major Reynaldo
May 2007
|
You can download a pdf manual for gdb here: I think these commands could spot your problem right away.
gdb->condition # mystery_variable == 0 This will stop the program as soon as mystery_variable becomes 0. This should tell you more than enough to fix your program.
My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
|
1
2
|