Date: Fri, 30 May 2014 00:27:20 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Neel Natu <neelnatu@gmail.com> Cc: freebsd-amd64@freebsd.org Subject: Re: i386 Go programs crash on amd64 Message-ID: <20140529212720.GK3991@kib.kiev.ua> In-Reply-To: <CAFgRE9FVWYQNTsbXK73kDyeG_MNUS7spKvbDtCT4poxbQ5BCpA@mail.gmail.com> 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> <CAFgRE9FVWYQNTsbXK73kDyeG_MNUS7spKvbDtCT4poxbQ5BCpA@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
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 <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?
Sure,
this also should be merged back to at least stable/8.
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQIbBAEBAgAGBQJTh6Y4AAoJEJDCuSvBvK1BN0oP9Ay+U5nlUA87WHryQVXjuhIp
c1fZta8FbXjidOcJPFi8wa/flTgyRwROBOaXp531P6czwT8jwK5/kMxlRqYIGhrb
TNQIoCWKYk4car24uhsFnxPCQdHlzNdGmvhyvDqUCVGo8k/Tn7mzGPb3Q6oM9LL+
oteFaAyziQS3SYNA4mlEO1sFzkuQvV99bg41gDvJHoXemIsekz06ud2Mbitkhwl8
vXUKvvh0HVhK4bfcD0RCc5+fFVx2DXJdjfYdESpTAr1o1+L478rqiKMRQHNICsp6
sl2Up/tJq8c4BE/HmzY8HTidvH9lx8Pmj86W1m2HNx+vsoPKmlMAJQumUVy5kH2N
iSRJvioONCUXwAW2y5KVcR7QzpFhpULA8GO/W8OB8lqbAoCyLkp8lvV0l3Jt3ZrU
HvRZObvk0dyAW1UuDi+CQFVHpgegG7vvxU1rc+H78z6BavONA11vAH67yG/iLT8q
yimiEZaJGzIVw/XQ4keIfYlI0KUnepMmVxJPtoOEQr2prU7kSt6XomheeZnyQ8gO
pefWan4+Q/Ne5XZ1Y0aHbsueQi/sq2soV3SDHqK0cBPKnF4HcJS4gZyhLCJ0KqbZ
Nq+o3SHioJOw1iUsnN6jgZRKNcZgKdJxrLPL8MD3E1SCqQ3dxAfKXAd5Ec48lSID
oAxVdFz2NqCBhdEiOrQ=
=lagm
-----END PGP SIGNATURE-----
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140529212720.GK3991>