From owner-freebsd-amd64@FreeBSD.ORG Thu May 29 21:28:30 2014 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BC666C8 for ; Thu, 29 May 2014 21:28:30 +0000 (UTC) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 492682992 for ; Thu, 29 May 2014 21:28:30 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id db11so1139877veb.1 for ; Thu, 29 May 2014 14:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hbx2zMriYo4JJFE+/JgiVJzasJwpY8ruCX0hDCy7jkU=; b=rBzF2BP2eeEc5CL406fiRj52gvRWzdGJq62XhSngTh5hFLseB7FXDH3epTMQZE0J7D 16JK5V5ZgcjeH0q1LP6CcQZQgmwcDs8sVHcxjnYoN/Bw4Nb1jxdDvnwGxKXF6M9iIivn zY1iLnoLbsw8x0Ci4/81aG95rQ7TkIn0BrjJFetJFh4aL3XPPBtxZAEgCibsEPQR9tj2 I9QIQBzKO0qBgHlHcvIfFKbkMLoSmc/cSOR2cy3iJbJqzlp49OnG2XprXWlC6EzkUx5P pCohQwuKvELUW+6Yv2hzlak9BFDznhGxHwcjKg09fS9x4mSYDRU3jF1loEJsFGVMlvuB O/9w== MIME-Version: 1.0 X-Received: by 10.220.182.5 with SMTP id ca5mr4207169vcb.50.1401398909370; Thu, 29 May 2014 14:28:29 -0700 (PDT) Received: by 10.52.146.39 with HTTP; Thu, 29 May 2014 14:28:29 -0700 (PDT) In-Reply-To: <20140529212720.GK3991@kib.kiev.ua> References: <537FD9A2.2010607@wemm.org> <20140523233444.GH74331@kib.kiev.ua> <20140524033944.GA96083@server.rulingia.com> <20140524074101.GI74331@kib.kiev.ua> <20140526113622.GB96083@server.rulingia.com> <20140526134457.GR74331@kib.kiev.ua> <20140528225542.GA46230@server.rulingia.com> <20140529013817.GF3991@kib.kiev.ua> <20140529104458.GA61598@server.rulingia.com> <20140529212720.GK3991@kib.kiev.ua> Date: Thu, 29 May 2014 14:28:29 -0700 Message-ID: Subject: Re: i386 Go programs crash on amd64 From: Neel Natu To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-amd64@freebsd.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 21:28:30 -0000 Hi Konstantin, On Thu, May 29, 2014 at 2:27 PM, Konstantin Belousov wrote: > On Thu, May 29, 2014 at 02:19:06PM -0700, Neel Natu wrote: >> Hi, >> >> On Thu, May 29, 2014 at 3:44 AM, Peter Jeremy wrote: >> > On 2014-May-29 04:38:18 +0300, Konstantin Belousov wrote: >> >>Hm, I think I know what is going on. Try this, please. >> >>At least, your test binary worked for me. >> > >> > Thank you. That seems to fix the problem even on non-trivial code. >> > >> >> Occasionally, I run into a problem where sys arch(I386_SET_LDT) fails >> with a ENOSPC. The golang runtime isn't checking the error return >> correctly and proceeds to load the bogus selector value into %gs. >> >> ./write >> pid 2571 comm write: signal 10 err e4 code 3 type 9 addr 0x8062446 rsp >> 0xffffdae8 rip 0x8062446 <8e e8 83 c4 20 c3 00 00> >> Bus error (core dumped) >> >> Here is the output of kdump: >> $ kdump >> capability mode sandbox enabled >> 1934 ktrace RET ktrace 0 >> 1934 ktrace CALL execve(0x7fffffffed2f,0x7fffffffeae0,0x7fffffffeaf0) >> 1934 ktrace NAMI "./write" >> 1934 write RET execve 0 >> 1934 write CALL sysarch(0x1,0xffffdb38) >> 1934 write RET sysarch -1 errno 28 No space left on device >> 1934 write PSIG SIGBUS SIG_DFL code=BUS_OBJERR >> 1934 write NAMI "write.core" >> >> In any case this is a problem because we aren't zeroing the LDT after >> allocation. Here is a patch that fixes it: >> >> Index: sys/amd64/amd64/sys_machdep.c >> =================================================================== >> --- sys/amd64/amd64/sys_machdep.c (revision 266856) >> +++ sys/amd64/amd64/sys_machdep.c (working copy) >> @@ -462,7 +462,7 @@ >> new_ldt = malloc(sizeof(struct proc_ldt), M_SUBPROC, M_WAITOK); >> new_ldt->ldt_base = (caddr_t)kmem_malloc(kernel_arena, >> max_ldt_segment * sizeof(struct user_segment_descriptor), >> - M_WAITOK); >> + M_WAITOK | M_ZERO); >> if (new_ldt->ldt_base == NULL) { >> FREE(new_ldt, M_SUBPROC); >> mtx_lock(&dt_lock); >> >> Ok to commit? > Sure, > this also should be merged back to at least stable/8. Thanks, will do. best Neel