Date: Wed, 22 Feb 2017 11:00:19 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Crash in 'system' while executing '__clone' 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.