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