My heap is corrupt. No I’m not talking about my car, or my house, but it’s a boring programming thing. Essentially, it means somewhere, I’ve been silly and have written code that writes to memory that it shouldn’t be. This is something that is very very hard to track down.

The trouble with C++, is it lets you do silly things. Not just write to memory that isn’t yours, you could do crazy stuff like define + as meaning subtract, and vice versa. C++ is the programming practical jokers language of choice. There are even competitions to see who can write the most unintelligble crap with it.*

Of course, I try to write the most sensible, intelligible code that I can. After all, I’m the poor schmuck who has to support it, and fend off bug reports from angry customers. The BIG problem with C++ is that when you write some code that does crazy stuff, even when it goes wrong, you might not know about it until much later, maybe seconds or even minutes later, which means hundreds of thousands, if not millions of lines of code have been processed since the actual error.

In other words, you can’t look at a call stack and see where you screwed up, which you can do, in 99% of bugs. Even multithreaded bugs can be at least reasonably interrogated with the call stack and watch window.

With a heap screwup like mine, you are back to pre-debugger, stone age thinking such as.
“When did this start happening”

“What had I done before it crashed? and what had I *not* done?”

The last one is especially helpful because it rules out certain causes. My crash is NOT a result of the level editor, the unit design screen, units exiting the map, nightvision, nighttime, order-giving or path-assigning. It happens in debug, and its only been happening the last week, maximum.

So that means I’ve probabyl screwed up the new pathfinding code or the new AI code. These are two recent areas of much rewriting. I’m combing through them right now. I’ve tried various tools and debug flags to help, but sadly they either don’t run, or slow the game to unplayable speeds, where the bug will likely never trigger.

Fun fun fun!

*C++ is FAST, which is why I use it. If you think 2D games don’t need speed, try cloning GSB or GTB to run at 1920 1200 res and run smoothly on a 4 year old video card. You NEED a lot of speed for all this stuff.

 

12 Responses to “Random heap corruption.”

  1. C# is beckoning you, you cannot resist forever. [/vader-voice]

  2. Wouter Lievens says:

    Perhaps you could run valgrind on your program?

  3. Luke, use boost. [/Obi-Wan-voice]

  4. cliffski says:

    apparently valgrind doesn’t run on windows.

  5. Marcus says:

    Hi Cliff

    Whenever I get one of these buggers I always use the Windows debugging SDK, which is really easy to enable and tracks lots of memory issues but really usefully raises an exception as soon as something overwrites certain parts of tracked memory

    http://www.devproconnections.com/article/net-framework2/debug-heap-issues-with-full-page-heap-129771

    Hope it helps…

    Marcus

  6. Grim says:

    You should try using Microsoft’s Windows Debugging Tools – pageheap.exe and gflags.exe are probably most relevant here, to help debug the heap corruption. http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

    There’s also an Application Verifier, but I’ve not used it personally. http://msdn.microsoft.com/en-us/library/ms220948.aspx

    Otherwise I use IBM Rational PurifyPlus at work for Windows. No idea how expensive it is.

    Good luck! Heap errors are a pain.

  7. Arowx says:

    Ouch, mind you I recently blew up Unity’s C# engine with a 9.9*million iteration loop to test Vector maths performance!

    For some reason in Unity it is faster to unroll the Vector maths x+x,y+y,z+z than let the library do it!

    So enjoy your speed!

    I thought you would have written your own memory management system, I’ve seen a few C++ threads on it, to get around performance issues with malloc?

    OK I’ll take the bait Unity C# 1920 x 1200 res how many ships and turrets, rates of fire and what FPS on your system?

  8. s1n says:

    C++ gets a bad wrap for things like this (unjustly IMHO), but IOCCC is for C (the first “C” stands for “C” itself). Anyone that suggests C# as a replacement clearly doesn’t understand the lure to C/C++ (bare metal access is useful).

    Have you looked into AMD CodeAnalyst? I think Intel has a similar tool that is Windows friendly.

    http://developer.amd.com/documentation/videos/pages/introductiontoamdcodeanalystperformanceanalyzer.aspx

  9. If it is always the *same* address that is corrupt, a hardware breakpoint on that address will let you quickly find the culprit.

    Also, I’m assuming you use revision control, I often find it helpful with these sorts of bugs to look through just my most recent changes (post bug showing up) with a Diff tool.

  10. cliffski says:

    yeah I’ve been going through changes but the crt functions for heap checking find it, so now its just a matter of narrowing my two crt debug checks each time it crashes to zero in on it. I think it’s pathing code.

  11. Den says:

    “C++ is FAST, which is why I use it. If you think 2D games don’t need speed, try cloning GSB or GTB to run at 1920 1200 res and run smoothly on a 4 year old video card. You NEED a lot of speed for all this stuff.”

    It is about skill rather than tool.

  12. “C++ is FAST, which is why I use it. If you think 2D games don’t need speed, try cloning GSB or GTB to run at 1920 1200 res and run smoothly on a 4 year old video card. You NEED a lot of speed for all this stuff.”

    To be fair, that’s a lot more to do with language-independent GPU performance, than CPU-based performance. Number of dynamic sprites on screen – that’d be more CPU-side (and, true, that’s what GSB/GTB has).

    Lots of fans of C# seem to suggest you switch to C# in comments (myself included). Because it’s really very good. Originally coming from a C++ background myself, I can see why you stick to C++. Not to mention your cost-of-changing reason, which, IMO, is by-far the more important reason.

    If I may suggest – you should be on the look-out for when you can do IL-level inlining and/or SIMD using C# (unrolling vector-maths for you, as Arowx points out). I’ve heard of people working on the former (unofficially) and Mono on the latter. Once those can be relied on, the performance deficit of C# vs C++ pretty much vanishes.