From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11073 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Crash in 'system' while executing '__clone' Date: Wed, 22 Feb 2017 11:00:19 -0500 Message-ID: <20170222160019.GT1520@brightrain.aerifal.cx> References: <20170222152739.yzscpa6ckyjdldwy@voyager> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1487779232 14148 195.159.176.226 (22 Feb 2017 16:00:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 22 Feb 2017 16:00:32 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11088-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 22 17:00:28 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cgZLA-0003JB-4P for gllmg-musl@m.gmane.org; Wed, 22 Feb 2017 17:00:28 +0100 Original-Received: (qmail 5586 invoked by uid 550); 22 Feb 2017 16:00:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5567 invoked from network); 22 Feb 2017 16:00:31 -0000 Content-Disposition: inline In-Reply-To: <20170222152739.yzscpa6ckyjdldwy@voyager> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11073 Archived-At: 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