FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

DEBUGGING

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.

Charlie Dickman


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.

Jay


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's also just as possible that the FB runtime loads some purgeable resources, for its own "private" purposes, and that some of these are left hanging around (however, if that were the case, I would expect that a lot more users would be complaining about the problem you're having).

Rick


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.
In fact I have given FB something like 10Mb to play around it and it 'never' causes problems. All problems I have encountered come down to (and however much I'd like to pretend the contrary sometimes) my stupidity.
If someone is debugging in tight memory, then it would be advisble to quit FB after every 4th or 5th warning, just to be sure that there is always enough memory around. But even then 'tight' would have to be real minimum requirements, and a nice big fat app.

jonathan