Re: memory protection

[Anthony Jacques <jacquesa@zetnet.co.uk>]

Hiya Pascal

>  KK> Actually teh memory protection mechanism in MiNT is not very useful and
>  KK> it somehow makes me think its done wrong. So it would be another bug in
>  KK> MiNT to fix. Why do I think so? Because the MP makes the system less
>  KK> stable instead of more stable. Many "non-MP-aware" programs lead the
>  KK> system to crash instead of getting killed.
>
> I have the same feeling. I usually run MiNT without MP because of this. For 
> example I'm not able to run Cab under Multitos (with MP) without a crash of 
> the system and technical information about PC, BSS and so on not useful for 
> me. So I run Multitos without MP but it seems to act as if it was working 
> in the reverse way as it should. (AFAICTell ;-) )

Well, you seem to be reporting correct operation of the Memory Protection
- when a program crashes with a message like:

pid  20 (CAB): MEMORY VIOLATION: type=private    AA=.. PC=.. BP=.. 
TEXT=.. BSS=..

it means that the CAB has attempted to access memory it shouldn't have - and
so should be provented from doing any harm to other programs - and so should
be killed.

The info that is dumped out can either be ignored, or passed to the author of
the program (along with info about what you were doing when it happened). Using
the ALERT.ACC prevents this information from corrupting the screen by putting
it in a GEM alert...

However, I have also witnessed a number of crashes with MP enabled where this
did not happen correctly (AIUI) - for example, I just ran an early version of
a program I am working on, which happens to kill MP (I have some dodgy memory
routs waiting to be replaced, so I'm not too supprised).

System: Falcon030, MiNT 1.14, AES 4.1, Thing 1.09e.

Running this program (coolabah), produced the following crash:

pid 16 (THING): MEMORY VIOLATION: type=private AA=3067D0 PC=2D3582 BP=28E000
pid  3 (AESSYS): MEMORY VIOLATION: type=free    AA=1AB15C PC=F8D12 BP=EA000
pid  3 (AESSYS): Operating System Killed
Fatal MiNT Error: adjust debug level and hit a key...
FATAL ERROR: You must reboot the system.

Now, how did that happen? Coolabah is not even listed as causing a violation,
yet running it managed to bring down the whole system!

It cannot have been Things fault, as that should have been killed before it can
do any harm. 

Now, maybe it was the AES's fault, but I'm not doing anything 
particularly unsual
in Coolabah (AFAIK), so I dont see why this should happen. I understand why if
the AES is killed, MiNT might want to quit (no shell left) - but I would have
thought that it would be much nicer if MiNT didn't report a fatal MiNT error...

Thoughts, anyone?

Anthony