Thread: BIG problem. How do I find a bug in so much code?

Add asserts to check for invalid program states.
Disable complex stuff that can cause random errors, ie threads.
Check common mistakes such as allocating memory before use.
Do logging of some kind.
Comment out code until it starts working properly.

You don't know asserts?
Basically assert(condition). If condition evaluates as false, in debug mode, it will break, so you can check where the heck things went wrong.
With debugging, I mean log all kinds of useful information such as what functions it enters, what values of arguments and information is, etc. Anything that might help you track down the problem.

you can compile you relase version with debug info, so if crash occures you can open debugger and exemine your variables. Of course - if you destroyed the stack with some buffer overrun - you will not see much... But still you will know that this is a problem... And if your just usign some not initialized var - you'll see it immediatly...

Of course, JIT may also help. With Visual Studio, whenever something crashes, you can debug. Then you can probably find out more about why the program crashes.

Originally Posted by brewbuck

What does the volume of code have to do with the difficulty of finding bugs?

Absolutely nothing. ;-) It is easier if you catch the bug sooner, so you have an idea of what code is breaking. However, that's not always possible.

If your program is segfaulting, a decent debugger should be able to tell you where. It should also give you a backtrace (what was passed to what functions), what the values in variables are, etc. Look for something out of the ordinary, something wrong, a pointer to garbage, etc. Then figure out why that number is wrong, and fix the appropriate code. (Sometimes the hard step.)

That's a typical logging scheme. It's great when shipping products to end users when it doesn't work for them as it should and the bug isn't obvious.

Random errors are quite annoying. They are often caused by bad management of array limits or using pointers after they have been freed, so checking such things using for example asserts is a good idea. A rarer case is "huge amount of recursion" - again, any recursion function that isn't explicitly bound should make sure it's counting the number of recursion levels and if it exceeds "double the maximum expected", you should cause an error in your application (e.g assert).

Also, if the application crashes, using the built-in debugger should work just fine - it will show you the stack as per where the application was when it crashed.

There is something called "defensive programming", which is based on the approach that "if something can go wrong, it will", and checking that things are right whenever there is a chance that it may be wrong.

Oh, and 1500 lines of code isn't a lot. I work on a project where our group is responsible for 2500+ files [that's just .cpp, .h and .c files, not counting "makefiles" and other files that are also part of the whole project]. One sub-project that I've been involved with consists of some 5-6 .cpp files and is 12000+ lines. Another sub-project has about 10 .cpp files and around 25000 lines each for two possible solutions for the same problem (choosen at build-time which of those two gets used)
.
--
Mats

If you use a log file, make sure you are flushing after each output operation. Since I/O is buffered, you may write something to a file in a function and when your program crashes, the output you do see may not match where the program really was at the time of the crash.

Are you running threads at all? If a program slows down a lot, it may yield enough CPU time to sync any threads/unmutexed variables you might have.

Also I see that you are destroying things (ie. torpedo). If your using a delete call, you should make sure that what your passing is a good pointer. Double deletes lead to heap errors, no deletes lead to memory leaks. I prefer using the SAFE_DELETE() macro, its a no-brainer when it comes to deleting things. It sets the pointer to NULL afterwards, which protects against double deletes. You might want to look into that, IMO.