Ahan Hsieh è¬æ¦æ¼¢ wrote:
> | |
> | |
> | |
> 0x60 +-------------+
> | |
> | | vfork() frame
> | |
> 0x100 +-------------+
> | |
> | | main() frame
> | |
> 0x200 +-------------+
> stack content before processes return vfork
> | |
> | |
> | |
> 0x60 +-------------+
> | |
> | | vfork() frame
> | |
> 0x100 +-------------+
> | |
> | | main() frame
> | |
> 0x200 +-------------+
> stack content after child return vfork
> | |
> | |
> 0x40 +-------------+
> | |
> | |
> | | execvp() frame
> | |
> 0x100 +-------------+
> | |
> | | main() frame
> | |
> 0x200 +-------------+
> stack content after child call execvp
> I observe that after the child process call the execvp(), the vfork()
> frame is corrupted.
> After the parent process returns from the vfork() system call, the
> vfork() frame is corrupted.
> So, unexpected result will be occured.
Nice idea :-)
vfork() has a special implementation, in assembly language, to make
sure the corrupted vfork() frame does not cause this problem.
For example, in uClibc the i386 implementation is this:
__vfork:
popl %ecx
movl $__NR_vfork,%eax
int $0x80
pushl %ecx
cmpl $-4095,%eax
jae __syscall_error
ret
Notice how the return address is saved in a register, %ecx, and
restored before returning. This prevents the problem you have thought
about.
All architectures have an assembly language vfork() function which
does something similar, for this reason.
-- Jamie
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
