Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 May 2014 14:19:06 -0700
From:      Neel Natu <neelnatu@gmail.com>
To:        Peter Jeremy <peter@rulingia.com>
Cc:        freebsd-amd64@freebsd.org
Subject:   Re: i386 Go programs crash on amd64
Message-ID:  <CAFgRE9FVWYQNTsbXK73kDyeG_MNUS7spKvbDtCT4poxbQ5BCpA@mail.gmail.com>
In-Reply-To: <20140529104458.GA61598@server.rulingia.com>
References:  <20140523225300.GA14433@server.rulingia.com> <537FD853.3000505@wemm.org> <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>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

On Thu, May 29, 2014 at 3:44 AM, Peter Jeremy <peter@rulingia.com> wrote:
> On 2014-May-29 04:38:18 +0300, Konstantin Belousov <kostikbel@gmail.com> 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?

best
Neel

> --
> Peter Jeremy



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFgRE9FVWYQNTsbXK73kDyeG_MNUS7spKvbDtCT4poxbQ5BCpA>