koobas.hobune.stream
Debugging crazy memory use & crash
I'm seeing bizarre behavior in a relatively new project. Sometimes, when running the game, Unity suddenly and unpredictably becomes unresponsive. Its memory usage (as reported by Windows) is growing rapidly, around 100MB/sec. Mercifully it usually crashes before it swaps my whole machine to disk. Sometimes it is accompanied by a "Fatal error in gc Too many heap sections" dialog.
Now...I've been programming for a long time, long enough to suspect that this is my fault. But I'm having a heck of a time figuring out how one finds things like this in Unity. At work, I'd just pop over to the debugger and "break all" as soon as the behavior starts happening. Here I don't have that luxury, nor do any of my hastily enabled breakpoints in MonoDevelop seem to get triggered. (I don't know if they are likely to be enable-able within a frame anyway.)
A bit more context for the curious: Most of what's running is a simple quadtree representation of passable/impassable areas of my map, and a very simple implementation of A* pathfinding, all in C#. Most of the time the A* works fine. But it seems like, for some combinations of start & goal points, this blow-up happens. I don't think it's a garden variety infinite loop within my A* code; certainly that's possible and I probably did screw it up, but there's just no way that would blow up like this. For one thing, the open and closed sets actually do use containers with set semantics (e.g. HashSet), and I'm not allocating new nodes, so there's really no way those could be growing unbounded. I think. In any event, the A* algorithm appears to be working and returning reliable (and obstacle avoiding) results. I don't even know if it's related, because I have no way of knowing what's on the stack when this explosion happens. That's so frustrating!
So my question is: Unity veterans, how would you go about tracking this down?
:) That sounds like you have created an infinite loop / recursion in your A* algorithm. If it's really a simple implementation it shouldn't be that hard to spot the flaw. If you can't find it, try to add a Debug.Log() when you trigger the A* routine and print out the parameters. Also add a Debug.Log() at the end when it successfully ended. If Unity crashs, just look into the logfile to see what parameters caused the crash.
YES! Thank you. The key piece of information here is that the log file is trustworthy. I just didn't know how to get a piece of output that was current as of the crash, given that the console window can't possibly be that immediately updated. I was even fantasizing about the bad old DOS days of using the keyboard lights as status indicators. (Yes, I'm that old.)
It certainly appears that you are right. It hadn't occurred to me that an infinite loop while putting together the final path would grow memory this quickly, but of course it does. There appears to be a bug in how I traverse the grid, since it's leaving behind a cycle. That will be a pain to debug, but at least I know where to look.
Thanks again.
EDIT: In case anyone runs across this, for posterity, here's what I screwed up in A*:
One way to retrieve an answer, once you have traversed the grid long enough to have reached your goal node, is to keep track of a "came from" node at each node you traverse, and then rewind it like a linked list once you get to goal.
Initially my hasty implementation was allocating new A* grid nodes for each pass. I recently changed it to a new quadtree representation that persists, but I forgot to clear out the "came from" node. It was sufficient to clear out the beginning node, since every other node will only be exa$$anonymous$$ed once it is set.
Bunny83, I am in your debt for making me trust Debug.Log.
