Jump to content
  • Advertisement
Sign in to follow this  
BS-er

Undebuggable bugs

This topic is 4251 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm using Visual C++ 2005 Express. I seem to be running into a class of bugs that I can't debug. The problem is that everything always runs fine when the program is launched from Visual C++ using the green "Start debugging" button, but I get crashes when running the program standalone. I know my start paths are correct, so from my perspective the programs are launching in an identical manner. I'm sure the IDE does something different when launching so that the program can be halted etc., but it's confusing why that would mask the bug that occurs when launching standalone. It's complicated by the fact that I'm using freeware libraries. I'm able to determine that adding this call or that causes the crash, but that's no major help. I need to call those functions! It's a very exasperating problem. Heck if I could just find out what the IDE does that keeps the bugs from happening, I'd build it into my code! Anyone experience similar issues? I'd be greatful for any suggestions that may clear this up. [Edited by - BS-er on November 27, 2006 7:14:27 PM]

Share this post


Link to post
Share on other sites
Advertisement
The first thing I typically do is try stepping through a debugger in order to get a feel for what values are being passed to and returned from functions while program execution, but since you say running from within VC++ seems to make it run just fine, you'll have to subscribe to an equivalent form of the printf school of debugging. If you have some logging mechanism in place, just start adding debug log messages... log things like functions being called, parameters passed to functions, return values returned from functions (especially library calls... usually this can give you some indication what to look more closely at). Granted putting in debug log messages will change the runtime behavior of your program, it's still better than nothing (unless of course it alters the runtime behaviour in such a way that the bug goes away... those are particularly nasty bugs to catch). One other thing you may want to try, and I haven't done this so I'm not too keen on how its done, is run the game and attach a remote debugger to the instance of your game. You can then set watchpoints and/or breakpoints, which may or may not give you some idea of what's going wrong. Without anymore specific details on the nature of your bug and whether it consistently happens, it is hard to give anymore specific or helpful advice.

Share this post


Link to post
Share on other sites
In my experience, it's one of these:
1. The debugger initializes values to some non-zero value, while the release one might not..
2. The debugger is slower, meaning the program runs slower, and takes longer to start. Right now I just can't figure out the scenario when I ran into this, but I do know it has happend.. Especially when dealing with threads this might happend (does any of your freeware libraries use threads?).

Share this post


Link to post
Share on other sites
Why don't you attach the debugger to the program after the crash and see where it crashed? Actually, Windows should give you the option to "Debug" a crashed program if you have a debugger installed/registered.

Also, I typically use a crash reporting tool like that of wxWidgets, or the stand-alone XCrashReport. With such a tool, you can use the crash (EIP) address generated to find out exactly where the program crashed.

Share this post


Link to post
Share on other sites
All so far are great and wonderful suggestions.

1 very low tech one is an attomic log to file function.
Then us a Macro that uses said function to print line number and file to said file.

once you zero in on the function and the line causeing the crash, you can use the log function to find out what is roughtly going on.

Macro I generally use is BFDB. It stands for Brute Force DeBugging.
It will make your app slower, so dosn't help in timming issue bugs. But it will work run in release mode.

Once th bugg is squished, its easy to either do a seach and replace, or just remove the macro body.

Share this post


Link to post
Share on other sites
In a recent experience debug vs release crashes usually happens when I forget to
initialize pointers to NULL during declaration then having something like
 
If (ptr!=NULL) delete ptr;
ptr = new something;


during debug, the pointers are initialized to NULL but not during
release, causing the delete to crash the program.

Share this post


Link to post
Share on other sites
The first step is use whatever debugger you use, make it crash, then get a backtrace on what caused it. Then you can find out how to solve it.

Share this post


Link to post
Share on other sites
I find it's easier to adopt good practices of the sort that make this class of bugs vanishingly rare. (This includes a lot of mostly simple things like using standard library containers and have specific idioms for using for-loops, declaring variables in a proper scope and near first use and initializing them with their first value; the occasional Boost widget; applying YAGNI - probably one of the most common sources of problems is needlessly making containers of pointers-to-object where containers of objects would suffice; refactoring the code to remove redundancy; etc. etc.)

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
I find it's easier to adopt good practices of the sort that make this class of bugs vanishingly rare. (This includes a lot of mostly simple things like using standard library containers and have specific idioms for using for-loops, declaring variables in a proper scope and near first use and initializing them with their first value; the occasional Boost widget; applying YAGNI - probably one of the most common sources of problems is needlessly making containers of pointers-to-object where containers of objects would suffice; refactoring the code to remove redundancy; etc. etc.)
You've replicated my thoughts exactly. Isn't hindsight wonderful?![smile]

But I would certainly try attaching the debugger when it crashes if he doesn't have time for a rewrite.[grin]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!