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

This is a discussion on BIG problem. How do I find a bug in so much code? within the C++ Programming forums, part of the General Programming Boards category; I am writing a game, and so far it consists of 1,474 lines. Aprx every 5 times I run it, ...

  1. #1
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,605

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

    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.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  2. #2
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,538
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,605
    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.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  4. #4
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,538
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    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...
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  6. #6
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,538
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    What does the volume of code have to do with the difficulty of finding bugs?

  8. #8
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    Quote 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.)
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

  9. #9
    The superhaterodyne twomers's Avatar
    Join Date
    Dec 2005
    Location
    Ireland
    Posts
    2,262
    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.

  10. #10
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,538
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,605
    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.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  12. #12
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Last edited by matsp; 01-28-2008 at 02:28 AM.
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  13. #13
    Registered User hk_mp5kpdw's Avatar
    Join Date
    Jan 2002
    Location
    Northern Virginia/Washington DC Metropolitan Area
    Posts
    3,799
    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.
    "Owners of dogs will have noticed that, if you provide them with food and water and shelter and affection, they will think you are god. Whereas owners of cats are compelled to realize that, if you provide them with food and water and shelter and affection, they draw the conclusion that they are gods."
    -Christopher Hitchens

  14. #14
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,605
    >> 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()
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  15. #15
    Codebot
    Join Date
    Jun 2004
    Location
    Toronto
    Posts
    195
    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.
    Founder and avid member of the Internationsl Typo Associateion

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problem Code: Inline
    By CodingFleet in forum C++ Programming
    Replies: 6
    Last Post: 07-25-2007, 11:19 AM
  2. Someone having same problem with Code Block?
    By ofayto in forum C++ Programming
    Replies: 1
    Last Post: 07-12-2007, 08:38 AM
  3. Quicksort problem, now with clear code
    By rvanbeusichem in forum C Programming
    Replies: 1
    Last Post: 11-25-2004, 12:54 PM
  4. Big Code, Little Problem
    By CodeMonkey in forum Windows Programming
    Replies: 4
    Last Post: 10-03-2001, 05:14 PM
  5. can anyone find the problem in my code
    By ArseMan in forum C++ Programming
    Replies: 2
    Last Post: 09-20-2001, 09:02 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21