Printable View
I am writing a game, and so far it consists of 1,474 lines. Aprx every 5 times I run it, it will "generate errors, and need to be closed by windows" at random times.
And there is little to go by, as they happen so random, I havn't a clue what is causing the error.
How do I find what's doing this, in so many lines? (I'm just thinking too, the game is nowhere even close to complete, so I should reach somthing like 7-9,000 lines. What would I do if somthing like this happens then!?!?)
Please help.
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.
The good part is, I'm almost positive that the problem is in a selected 800 lines, the rest is 'template' code that I made which has been working for me just fine in other programs.
Asserts?
That's all done in my 'template' code, so I don't think thats the problem. I must have more loops than a road map in my 800 lines, I thought it might have been an error with them, but when it is my programs freeze up and toture the cpu, not crash.
Logging like how?
That's why this is so confusing, all of the code works, and is in use while running the game. What's happening is code that was working suddenly stops working... somewhere.
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.
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.Quote:
Originally Posted by brewbuck
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.)
When I find my programs crash at random points I make an output file and at strategic positions (like start of functions, end of loops etc), I write something unique to file which will show where the code is at and some variables. When the program crashes the last marker will tell me roughly where the bug is. That's when I didn't use the debugger, mind.
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.
Huh, I really like the log file idea. I'll try that, and then come back.
Also, how do you operate dev's debugger anyway? I've never used it before.
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.
>> Random errors are quite annoying.
You can say that again.
Maybe I don't have alot of code, but for just me and in one cpp & h file it kinda is.
What is the code for that your group is responsible for?
This morning I made the file logging, it went fairly quick, but now when it's activated, my game drops down to 2-1 fps. So now the error doesn't even happen when I run it. (like I said, it only happens some of the time.)
Here is one frame from my log file. (working)
Code:// Do the stuff
ThrustShip(0, TRUE)
ai(1)
aiFindClosest(1, -1, 3)
FireWeapon(1, 2, TRUE, TRUE)
FireWeapon(1, 2, TRUE, FALSE)
FireWeapon(1, 2, FALSE, TRUE)
FireWeapon(1, 2, FALSE, FALSE)
ai(2)
aiFindClosest(2, -1, 3)
ThrustShip(2, TRUE)
FireWeapon(2, 3, TRUE, TRUE)
FireWeapon(2, 3, TRUE, FALSE)
FireWeapon(2, 3, FALSE, TRUE)
FireWeapon(2, 3, FALSE, FALSE)
ai(3)
aiFindClosest(3, -1, 3)
FireWeapon(3, 1, TRUE, TRUE)
FireWeapon(3, 1, TRUE, FALSE)
FireWeapon(3, 1, FALSE, TRUE)
FireWeapon(3, 1, FALSE, FALSE)
ai(4)
aiFindClosest(4, -1, 3)
ThrustShip(4, TRUE)
FireWeapon(4, 6, TRUE, TRUE)
FireWeapon(4, 6, TRUE, FALSE)
FireWeapon(4, 6, FALSE, TRUE)
FireWeapon(4, 6, FALSE, FALSE)
ai(5)
aiFindClosest(5, -1, 3)
ThrustShip(5, TRUE)
FireWeapon(5, 4, TRUE, TRUE)
FireWeapon(5, 4, TRUE, FALSE)
FireWeapon(5, 4, FALSE, TRUE)
FireWeapon(5, 4, FALSE, FALSE)
ai(6)
aiFindClosest(6, -1, 3)
ThrustShip(6, TRUE)
FireWeapon(6, 1, TRUE, TRUE)
FireWeapon(6, 1, TRUE, FALSE)
FireWeapon(6, 1, FALSE, TRUE)
FireWeapon(6, 1, FALSE, FALSE)
ai(7)
aiFindClosest(7, -1, 3)
ThrustShip(7, TRUE)
FireWeapon(7, 4, TRUE, TRUE)
FireWeapon(7, 4, TRUE, FALSE)
FireWeapon(7, 4, FALSE, TRUE)
FireWeapon(7, 4, FALSE, FALSE)
TorpedoImpact(0)
TorpedoImpact(1)
TorpedoImpact(2)
TorpedoImpact(3)
TorpedoImpact(4)
TorpedoImpact(5)
TorpedoImpact(6)
TorpedoImpact(7)
TorpedoImpact(8)
TorpedoImpact(9)
TorpedoImpact(10)
TorpedoImpact(11)
TorpedoImpact(12)
TorpedoImpact(13)
TorpedoImpact(14)
TorpedoImpact(15)
TorpedoImpact(16)
TorpedoImpact(17)
TorpedoImpact(18)
HurtShip(6, 5, 7)
DamageRandomSystem(6)
DestroyTorpedo(18)
TorpedoImpact(18)
TorpedoImpact(19)
TorpedoImpact(20)
TorpedoImpact(21)
// Draw the stuff
DrawGLScene()
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.