From mint-bounce@lists.fishpool.fi Fri Jun 12 05:30:32 2009 X-Virus-Scanned: amavisd-new at demon.co.uk Subject: Re: [MiNT] Corruption of high TPA From: Alan Hourihane To: Vincent =?ISO-8859-1?Q?Rivi=E8re?= Cc: mint@lists.fishpool.fi In-Reply-To: <4A321C86.6000608@freesbee.fr> References: <4A2ED03D.1090600@freesbee.fr> <4A2F7B9F.3010100@freesbee.fr> <4A30FE49.3050404@freesbee.fr> <1244725809.15756.100.camel@jetpack.demon.co.uk> <4A310791.2020709@freesbee.fr> <1244728568.15756.106.camel@jetpack.demon.co.uk> <4A311332.90806@freesbee.fr> <1244731278.15756.109.camel@jetpack.demon.co.uk> <1244748327.4731.8.camel@joy> <4A316B4E.7020303@freesbee.fr> <1244788520.12354.27.camel@petr> <4A320C47.5090909@freesbee.fr> <1244794878.12354.35.camel@petr> <4A321C86.6000608@freesbee.fr> Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 12 Jun 2009 10:24:23 +0100 Message-Id: <1244798663.29866.2.camel@jetpack.demon.co.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: alanh@fairlite.co.uk Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.sparemint.org id n5C9UW45005715 On Fri, 2009-06-12 at 11:14 +0200, Vincent Rivière wrote: > Petr Stehlik a écrit : > > I thought it was the same story - copying more bytes from the original > > stack than necessary thus reading from memory the process does not own. > > Luckily it was easy to fix EmuTOS. > > Yes, we are confused ;-) > > You are right, the problem is the same in the FreeMiNT trap #1 handler > as it was in the EmuTOS one. The OS reads too much data from the stack. > Thus it crashes when the address space after the stack is not readable. > > But the reason why the "memory" after the stack is not readable is > different in the 2 scenarios. > In EmuTOS, it crashes because there is nothing valid after the stack, it > is the end of the FastRAM. > In FreeMiNT with memory protection, it crashes because the memory after > the stack is made unreadable by the MMU. > > 2 different scenarios, but the same kind of bug in the trap handler. > > > Sorry but this sounds like the 64 bytes adjustment is still not enough > > and the program keeps crashing on FreeMiNT? But if it was crashing you > > couldn't read the numbers.... I am confused :) > > If I initialize the stack to the end of the TPA minus 64 bytes, it does > not crash anymore. By doing this, we ensure that if some buggy os reads > too much data from the stack, it will stay in the process TPA area, so > it will not crash. > By looking quickly at the FreeMiNT sources, we can see that on trap #1 > it always reads 36 bytes from the stack. EmuTOS was reading only 2 or 4 > additional bytes, I don't remember. > > So if in the MiNTLib startup code we keep 64 unused bytes at the top of > the stack inside the TPA area, it will probably be enough as a > workaround for any buggy OS. > > Adding a workaround in the MiNTLib is good, but fixing FreeMiNT like > EmuTOS would be even better ! Sure. We're going to need to fix MiNTlib anwyay for buggy kernels. So please go ahead with this Vincent. I'll take a look at FreeMiNT on my next pass. Alan.