Deal with memory leak using Debug II
I've had private communication with Staz regarding this phenomenon and the bottom line is, from Staz himself, that this is an artifact of how the debugger runs within FB. The time to be concerned is when this number increases the longer you run your app or the more times you perform some particular function within it. For example, if the amount of unrecoverable memory went up each time you prepared a gWorld and copied it to the screen then you should be concerned about a memory leak associated with that function.
I never think to look at tech notes until someone mentions them here. Is there one about this? Seems like a good candidate--at least for those wise enough to actually read them. Just when I had really taken to heart the message, "The problem is not in FB, it's somewhere in your code," I learn that might not always be the case. A little disconcerting, but I feel better nonetheless.
Is it possible that you are loading some resources that aren't getting released? Even a call to RELEASERESOURCE does not always actually release the resource (for example, if you make a change to a resource in memory and then call RELEASERESOURCE, the resource doesn't actually get removed from memory until the resource file is closed). Also, if you are using purgeable resources and depending on the Memory Manager to release the memory as necessary, it may or may not have released all the blocks when your program finishes.
It is a quite common 'problem' when quitting with the debugger running. I remember posting myself on this subject years back. And I was reassured then that - from debugger, and providing the amount of memory hung up was always pretty much the same - it was 'normal' behavior.