Fine tuning_and_troubleshooting_memory_protection

FreeMiNT implements the memory protection in a way that allows some user tuning. The way the program's memory space can be protected is encoded in the program's binary file header. Using programs like the Thing desktop you can try changing the protection status of a program and test the behavior. As a rule, if a program runs fine with the "Private" status, you should leave the things as they are. If it does not, the next tested status should be "Readable", then "Super", and finally "Global".

Common problems

• A program tries to access memory that belongs to another program. The system alert that appears then, mentions a memory violation "type private". Paradoxally, the program, that has been shot down this way, may not be guilty. For example that your desktop gets killed due to memory violation "type private", when you attempted to open a ST-Guide hypertext. In this case the desktop is the innocent part - it has been told by ST-Guide to access memory owned by ST-Guide and not accessible to other programs.

• GEM programs using the AV protocol or other message protocols. The AV protocol (and some other protocols like OLGA or DHST) pass pointers to information in it's own memory to other programs. The receiving program then reads from or writes to this memory location. If the sender doesn't know (or care) about memory protection, the receiver will be killed when it tries to access the memory it has been told to access. The ST-Guide example previously mentioned is a typical case. The solution is to set the sending program's protection mode to "Readable", or in some cases "Global".

• A program tries to access memory that does not belong to anyone. It is called "memory violation type free". This usually means there's a bug in the program, and we cannot do much about this (except asking the author to fix the bug). This is a good example of memory protection working at it's best - it has prevented a program from accessing memory it doesn't own due to a bug.

• A program causes a complete system crash. Examples are: Pure Debugger, X-Boot III or Dump! module player. Paradoxally, as it is with the mentioned programs, it may be the easiest to fix - it is enough to change the protection status to "Supervisor".

If the program still does not work, it may be worth to give it a try without memory protection. However, you're encouraged to run the system in memory protected mode (unless it is completely unacceptable for you). Running programs that doesn't work with memory protection means that you are using a program that access memory it doesn't own. This may cause problems for other applications, or the system might crash.

Compatibility list

• FreeMiNT Memory Protection Compatibility list