"You must have dereference a null pointer!"

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Hehe, I spent 45 minutes on Thursday debugging a crash bug in the initialization code of Rat Race. The problem? Attempting to access a NULL pointer.

      I've found this to be the most common cause of crashes in games.

    • This is quite ironic, as I spent a part of thursday adding the following asserts to various places in the initialization code:

      Source Code

      1. assert(NULL!=pMyPointer && "We expect pMyPointer to not be NULL by this point, something has gone wrong.")

      ...where pMyPointer is a return value from some factory function for a third party library.
    • Wel, think about it... invalid pointers are the only reason a game would crash (outside of crazy device issues).

      I hate when the null pointer is an object, and you are deep inside a method before it actually crashes.
      -Larrik Jaerico

    • Yay for data break points! With data breakpoints, you can catch the exact second something changes. This doesn't help you if you're dereferencing a deleted object (shame on you for not using a SAFE_DELETE macro!), but they can be quite handy.

    • That's what I do when I code in Perl. I loathe the Perl debugger and it's usually just faster to sprinkle a bunch of "print $someVar if $debugShowVals;" statements everywhere.