[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] vfork bug, help needed



Hi!

On Thu, Mar 09, 2000 at 04:35:33PM +0100, Guido Flohr wrote:
> Somewhere either in the MiNTLib or in the kernel there is a bug in vfork.

Not having looked at the code yet, but from experience: After a
Pvfork(), parent and child _share_ memory. This includes the stack. The
parent is stopped, but that doesn't hinder the child to overwrite the
stack with whatever it does after the Pvfork(). Just saving the return
address for the parent isn't enough, because the child will most
probably overwrite the registers saved before the library wrapper was
called.

I recall having that problem in XaAES when compiling for Pure C, where
Pvfork() wasn't an inline, but a subroutine call. In your case, vfork()
is a library call, anyway, so it might help a bit to make it an inline
function, but that's not enough, of course.

In XaAES, I worked around the problem by duplicating some 100 bytes of
stack for the parent, restoring them when it woke up again. But of
course, this is still not a real solution, because 100 bytes (or more or
less) is just a value of the type "let's hope that's enough" - there's
no way to tell how much stack space the child will clobber, and it's
also possible that the child will clobber the area those 100 bytes were
copied to (they have to reside on the stack as well, or the call
wouldn't be re-entrant) if it calls some nested functions.


Ciao

Thomas


-- 
Thomas Binder (Gryf @ IRCNet)  gryf@hrzpub.tu-darmstadt.de
PGP-key available on request!  binder@rbg.informatik.tu-darmstadt.de
Vote against SPAM:             http://www.politik-digital.de/spam/

Attachment: pgpLSwFL0R2zS.pgp
Description: PGP signature