Memory protection in Mint

Hardware, coding, music, graphic and various applications

Moderators: Mug UK, moondog/.tSCc., lp, [ProToS], Moderator Team

mzry
Captain Atari
Captain Atari
Posts: 348
Joined: Tue Jan 26, 2016 12:39 pm

Memory protection in Mint

Postby mzry » Wed May 16, 2018 5:20 am

Hi all,

I've always wondered whether people run with this on or not. I usually find that my machine runs best with it off. When I turn it on apps will be closed down often, even the OS itself has crashed on me.

What are peoples opinions?

Thx

joska
Hardware Guru
Hardware Guru
Posts: 3925
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Memory protection in Mint

Postby joska » Wed May 16, 2018 6:06 am

Always on :) If it works "better" with mp off, then it works by coincidence.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mzry
Captain Atari
Captain Atari
Posts: 348
Joined: Tue Jan 26, 2016 12:39 pm

Re: Memory protection in Mint

Postby mzry » Wed May 16, 2018 6:13 am

Thx, I'll try running with it on and see how I go. I was probably just running some bad programs.

jury
Captain Atari
Captain Atari
Posts: 251
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: Memory protection in Mint

Postby jury » Wed May 16, 2018 6:56 am

mzry wrote:I've always wondered whether people run with this on or not.


Always off

vido
Atari Super Hero
Atari Super Hero
Posts: 564
Joined: Mon Jan 31, 2011 7:39 pm

Re: Memory protection in Mint

Postby vido » Wed May 16, 2018 7:06 am

Always on if possible.

But yes, you have to find out what software makes troubles with MP on. I missed the most Freedom file selector.

joska
Hardware Guru
Hardware Guru
Posts: 3925
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Memory protection in Mint

Postby joska » Wed May 16, 2018 7:17 am

The most common cause for problems related to memory protection is applications using the AV-protocol. This protocol does not pass data, but pointers to data. If this data is located in private memory the recipient of the data will be violating memory protection and subsequently killed.
One example: The first thing an AV-aware application should do is to the send the AV_PROTOKOLL message to the AV-server. This message contains among other things a pointer to the name of the application. If this string is located in the application's private memory, the AV-server (desktop) will be killed by MiNT for violating memory protection. The solution is to change the memory protection flags for this application to "readable", this can be done with Thing! (and probably other tools too). This will allow other applications to READ data from the application's memory, but not write anything. This will fix most, if not all, memory protection issues with the AV protocol.

There are ofcourse other reasons too, there are more protocols like the AV-protocol (DHST - Document HiSTory protocol, OLGA - Object Linking for Gem Applications, StIc - icon protocol etc) that exchange pointers to data in private memory. And another common reason for memory violation is buggy software - due to bugs they attempt to read (or worse, write!) data in memory belonging to other applications. Disabling memory protection can "fix" the latter, but usually with a cost - poking around and writing to random locations can cause other applications to crash or subtly damaging their data.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

joska
Hardware Guru
Hardware Guru
Posts: 3925
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Memory protection in Mint

Postby joska » Wed May 16, 2018 7:20 am

vido wrote:I missed the most Freedom file selector.


Freedom 1.15 is working fine with memory protection, I've been using it (with mp enabled) for 20 years now. Freedom 2 is very buggy and should be avoided. It is also a good example of what happens when developers can't restrict themselves, in version 2 Freedom went from a super nice file selector to a tool that attempted to do everything but ended up doing nothing really well.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

User avatar
shoggoth
Nature
Nature
Posts: 900
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: Memory protection in Mint

Postby shoggoth » Wed May 16, 2018 7:32 am

Embracing memory protection means ditching some ill-behaved applications, but once that's done things are very stable. It's also a blessing when coding, since rogue pointers generally leads to a program termination rather than a freeze/hang.
Ain't no space like PeP-space.

joska
Hardware Guru
Hardware Guru
Posts: 3925
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Memory protection in Mint

Postby joska » Wed May 16, 2018 7:51 am

shoggoth wrote:It's also a blessing when coding, since rogue pointers generally leads to a program termination rather than a freeze/hang.


This is exactly why I'm not using my Firebee for coding anymore.
Jo Even

Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mikro
Atari God
Atari God
Posts: 1481
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Memory protection in Mint

Postby mikro » Wed May 16, 2018 8:40 am

Always on. To extend Joska's answer, there's another trick / reason why use the flags dialog: demos and games. They usually hang on some system vector (like VBL) which is OK if done in Supervisor but as soon as the vector is triggered you get memory violation: the routine is in application's user space while the vector is accessed by the kernel. So the solution here is to use the "Super" flag indicating that Supervisor-enabled application (read: the OS) can access that application's memory.

I'm not entirely sure about the following but I think the reason why it doesn't work with "Private/readable" is that the handler hooked on the system vector usually also writes some data into that application's user space (data/bss) therefore violating the read-only contract.

PeterS
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 148
Joined: Fri Nov 09, 2007 1:53 pm
Location: England, GB

Re: Memory protection in Mint

Postby PeterS » Wed May 16, 2018 12:14 pm

joska wrote: The solution is to change the memory protection flags for this application to "readable", this can be done with Thing! (and probably other tools too). This will allow other applications to READ data from the application's memory, but not write anything. This will fix most, if not all, memory protection issues with the AV protocol.


Always had mp off since it crashed Thing (due to AV protocol).

I didn't know there was a workaround. I will give it a try and see what happens.

ThorstenOtto
Captain Atari
Captain Atari
Posts: 269
Joined: Sun Aug 03, 2014 5:54 pm

Re: Memory protection in Mint

Postby ThorstenOtto » Wed May 16, 2018 2:16 pm

PeterS wrote:I didn't know there was a workaround. I will give it a try and see what happens.


The problem is that there are a lot of applications not properly allocating the storage for things passed via AV protocol (or others). It's not even their fault, because the AV protocol was introduced long before MiNT came up with MP.

Another problem is that it is not the faulty application that is killed, but the one which receives the parameters and tries to access them. So it is not always easy to determine which app to blame.

OL
Captain Atari
Captain Atari
Posts: 475
Joined: Fri Apr 01, 2005 6:59 am
Contact:

Re: Memory protection in Mint

Postby OL » Wed May 16, 2018 7:58 pm

joska wrote:The most common cause for problems related to memory protection is applications using the AV-protocol. This protocol does not pass data, but pointers to data. If this data is located in private memory the recipient of the data will be violating memory protection and subsequently killed.
One example: The first thing an AV-aware application should do is to the send the AV_PROTOKOLL message to the AV-server. This message contains among other things a pointer to the name of the application. If this string is located in the application's private memory, the AV-server (desktop) will be killed by MiNT for violating memory protection. The solution is to change the memory protection flags for this application to "readable", this can be done with Thing! (and probably other tools too). This will allow other applications to READ data from the application's memory, but not write anything. This will fix most, if not all, memory protection issues with the AV protocol.

There are ofcourse other reasons too, there are more protocols like the AV-protocol (DHST - Document HiSTory protocol, OLGA - Object Linking for Gem Applications, StIc - icon protocol etc) that exchange pointers to data in private memory. And another common reason for memory violation is buggy software - due to bugs they attempt to read (or worse, write!) data in memory belonging to other applications. Disabling memory protection can "fix" the latter, but usually with a cost - poking around and writing to random locations can cause other applications to crash or subtly damaging their data.



AV protocol is not really an issue with MP, try MyAES in protected mode with a software crashing on AV protocol on other AES it should not so it can be fixed, I do it several years ago if you find a software crashing on AV please send me it to try to complete the fix. Except this I think XaAES crash less application than MyAES in protected mode!

I like protected mode for development but in normal use MP is quite crazy most problems are link to program adding vector, if they crash all the system crash in same time! A software should not be able to add system vector in MP, only drivers.
OL

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12283
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: Memory protection in Mint

Postby wongck » Thu May 17, 2018 4:44 am

Normal usage - off
Development testing - on
My Stuff: FB/Falcon CT63/CTPCI+ATI+RTL8139+USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

User avatar
jfl
Atari Super Hero
Atari Super Hero
Posts: 851
Joined: Tue Jul 18, 2006 10:55 pm
Location: Liège, Belgium
Contact:

Re: Memory protection in Mint

Postby jfl » Thu May 17, 2018 5:57 am

joska wrote:
shoggoth wrote:It's also a blessing when coding, since rogue pointers generally leads to a program termination rather than a freeze/hang.

This is exactly why I'm not using my Firebee for coding anymore.

I hear ya. I no longer have a choice since my FireBee is my only Atari but I miss MP a lot. I have to test my code with Aranym sometimes; which is not a bad thing in itself but a step I could live without.
Jean-François
GEMDict – GEMClip

User avatar
jfl
Atari Super Hero
Atari Super Hero
Posts: 851
Joined: Tue Jul 18, 2006 10:55 pm
Location: Liège, Belgium
Contact:

Re: Memory protection in Mint

Postby jfl » Thu May 17, 2018 5:17 pm

jfl wrote:
joska wrote:
shoggoth wrote:It's also a blessing when coding, since rogue pointers generally leads to a program termination rather than a freeze/hang.

This is exactly why I'm not using my Firebee for coding anymore.

I hear ya. I no longer have a choice since my FireBee is my only Atari but I miss MP a lot. I have to test my code with Aranym sometimes; which is not a bad thing in itself but a step I could do without.

Edit: sorry for the double post, I clicked reply instead of edit :x
Jean-François
GEMDict – GEMClip


Social Media

     

Return to “Professionals”

Who is online

Users browsing this forum: No registered users and 2 guests