Re: Crash in 'system' while executing '__clone'

[Rich Felker <dalias@libc.org>]

On Wed, Feb 22, 2017 at 04:27:39PM +0100, Markus Wichmann wrote:
> On Wed, Feb 22, 2017 at 11:44:12AM +0000, Tobias Koch wrote:
> >     16syscall
> >     (gdb)
> >     17test %eax,%eax
> >     (gdb) backup    git       pkgs      repo      spool     temp.txt  test      test.c    test.txt
> > 
> 
> OK, so the clone call was successful. Good. In system() we clone with
> vfork() semantics, so the caller is blocked until the child exec()s.

The code does not actually rely on that; CLONE_VFORK is just an
optimization hint to prevent the kernel from scheduling the parent
only to have it immediately block (it also avoids mis-emulation bugs
in qemu app-level emulation). It's safe for the parent to run here
because the child has a separate stack; deallocation of the child
stack is protected by additional synchronization with the child.

> BTW, what's with the line numbers? Why are they doubled (up in the
> single digits)?
> 
> >     18jnz 1f
> >     (gdb)
> >     __clone () at src/thread/x86_64/clone.s:27
> >     271:271ret(gdb)
> >     0x0000000000000000 in ?? ()
> > 
> > Any ideas what might be wrong or what I can do to investigate further?
> > 
> > Tobias
> 
> So the last few steps mean that the ret instruction loaded a zero into
> RIP. Which means that [rsp] has been replaced with a zero byte.
> 
> I'd probably debug this again, setting a watchpoint on the value RSP is
> pointing to. Then set the debugger to follow a created child (set
> follow-fork-mode child) and run this snippet again. As I said, vfork()
> semantics are in use, i.e. the child process might clobber the return
> address of its parent.

Yes, this sounds like a good debugging approach, even though what
seems to be happening shouldn't be possible.

Rich