On Sun, Jun 20, 2010 at 12:28 AM, John David Anglin
<dave@xxxxxxxxxxxxxxxxxx> wrote:
> Carlos,
>
>> I have constructed a vfork test case which shows some of the problems
>> I have using vfork reliably. This fails every time on my PA8700 system
>> running 2.6.32-rc6. It appears as though r28 (ret0) in the parent is
>> being corrupted.
>
> It seems the vfork implementation has changed in 2.11.1 from
> using clone to the vfork syscall. I tried to build gdb head
> today, but it dies at startup due to a problem with vfork. This
> is potentially also an issue with gcc as it uses the same
> libiberty code.
On hppa calling vfork in a non-multithreaded environment does the following:
vfork [vfork.c] ->
__fork (__libc_fork) [nptl/fork.c, linux/fork.c] ->
ARCH_FORK (clone syscall) []
On hppa in a multithreaded environment (linked against libpthread.so)
vfork does the following:
vfork ->
vfork syscall (pt-vfork.S)
This has not changed in 2.11.1.
Could you please elaborate on the change that you believe occurred in 2.11.1?
> I filed a sourceware bug, but closed it when I realized that
> this is a glibc/kernel bug:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11730
>
> After spending some time looking at this, I realized that __vfork
> is broken. It should not allocate a frame as the child may clobber
> the parent's frame when it does a call, etc. A frame should only
> be allocated and popped around the call to the syscall error handler.
Oh dear, yes I see. After the child returns from vfork, it calls exec,
clobbering the vfork frame that the parent must still unwind from. Is
that what you mean?
Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
