That doesn't sound very nice. Is that all that is required? Just typing AVAIL FLUSH in a shell? I better try again just to be sure.
It's relatively easy to make sure memory gets freed when a program quits, even if the program was badly written and forgot to free it. If the program only uses the C standard malloc()/calloc()/realloc()/free() family of functions (or C++ new/new[]/delete/delete[]), since the standard library can keep track of all allocations. If the application uses AmigaOS memory pools, it is also possible to ensure memory is freed. Only direct calls to AllocMem() that are never freed are likely to cause genuine leaks on exit. This is compounded by the fact that under AmigaOS, you can free bits of an allocated block of memory. That's not easy to track.
Freeing the same memory twice isn't something that is easy to protect against for any system. My own code uses a tracking system that knows all the blocks that were allocated by it and will throw an exception when any code tries to free something not in that list. However, this doesn't come for free, you have to step through the list of all allocated blocks and check the pointer doesn't match any of them. I'm pretty sure the C standard library is capable of doing this (and in current versions of glibc I think it does), but the standard makes it clear that freeing memory at the same address twice is undefined and bad.
If you free memory using AmigaOS FreeMem() and give it an area that wasn't allocated with AllocMem() in the first place, you basically trash exec's free memory list. That tends to make the system unstable.
It isn't the Avail command that is to blame, it's whatever left the free memory list in a state.
