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