Failure log: http://package18.nyi.freebsd.org/data/112amd64-default-PR208580/2019-01-30_23h37m30s/logs/errors/go14-1.4.3_3.log Peter reports that this patch fixes it: +++ src/runtime/mem_freebsd.c 2019-02-14 01:27:32.087512000 -0800 - p = runtime.mmap(v, n, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0); + p = runtime.mmap(v, n, PROT_READ|PROT_WRITE, MAP_ANON|MAP_FIXED|MAP_PRIVATE, -1, 0);
https://reviews.freebsd.org/D19194 is the supposed fix. Or set vm.cluster_anon to 0.
*** Bug 239132 has been marked as a duplicate of this bug. ***
Anyone can confirm this fixed it? so we can close the PR?
The build still fails for me on 12.0-STABLE r351809: $ sysctl kern.elf64.aslr kern.elf64.aslr.stack_gap: 3 kern.elf64.aslr.honor_sbrk: 1 kern.elf64.aslr.pie_enable: 1 kern.elf64.aslr.enable: 1 $ sysctl vm.cluster_anon vm.cluster_anon: 0 ... go/build cmd/go runtime: address space conflict: map(0xc208000000) = 0xc2086fc000 fatal error: runtime: address space conflict runtime stack: runtime.throw(0x7e5006) /usr/local/go14/src/runtime/panic.go:491 +0xad fp=0x7fffff8d81e8 sp=0x7fffff8d81b8 runtime.SysMap(0xc208000000, 0x100000, 0x0, 0x8027b8) /usr/local/go14/src/runtime/mem_freebsd.c:90 +0xd3 fp=0x7fffff8d8220 sp=0x7fffff8d81e8 runtime.MHeap_SysAlloc(0x807ea0, 0x100000, 0x4978d2) /usr/local/go14/src/runtime/malloc.c:284 +0x124 fp=0x7fffff8d8278 sp=0x7fffff8d8220 MHeap_Grow(0x807ea0, 0x8, 0x0) /usr/local/go14/src/runtime/mheap.c:398 +0x58 fp=0x7fffff8d82b8 sp=0x7fffff8d8278 MHeap_AllocSpanLocked(0x807ea0, 0x1, 0x0) /usr/local/go14/src/runtime/mheap.c:298 +0x365 fp=0x7fffff8d82f8 sp=0x7fffff8d82b8 mheap_alloc(0x807ea0, 0x1, 0x12, 0x0) /usr/local/go14/src/runtime/mheap.c:190 +0x121 fp=0x7fffff8d8320 sp=0x7fffff8d82f8 runtime.MHeap_Alloc(0x807ea0, 0x1, 0x10000000012, 0x476b4e) /usr/local/go14/src/runtime/mheap.c:240 +0x66 fp=0x7fffff8d8358 sp=0x7fffff8d8320 MCentral_Grow(0x80fc18, 0x0) /usr/local/go14/src/runtime/mcentral.c:197 +0x8b fp=0x7fffff8d83c0 sp=0x7fffff8d8358 runtime.MCentral_CacheSpan(0x80fc18, 0x0) /usr/local/go14/src/runtime/mcentral.c:85 +0x167 fp=0x7fffff8d83f8 sp=0x7fffff8d83c0 runtime.MCache_Refill(0x80175f000, 0x12, 0x0) /usr/local/go14/src/runtime/mcache.c:90 +0xa0 fp=0x7fffff8d8420 sp=0x7fffff8d83f8 runtime.mcacheRefill_m() /usr/local/go14/src/runtime/malloc.c:368 +0x57 fp=0x7fffff8d8440 sp=0x7fffff8d8420 runtime.onM(0x729f70) /usr/local/go14/src/runtime/asm_amd64.s:273 +0x9a fp=0x7fffff8d8448 sp=0x7fffff8d8440 runtime.mallocgc(0x120, 0x693c60, 0x0, 0x800000000) /usr/local/go14/src/runtime/malloc.go:178 +0x849 fp=0x7fffff8d84f8 sp=0x7fffff8d8448 runtime.newobject(0x693c60, 0x80175f000) /usr/local/go14/src/runtime/malloc.go:353 +0x49 fp=0x7fffff8d8520 sp=0x7fffff8d84f8 runtime.newG(0x4903ea) /usr/local/go14/src/runtime/proc.go:233 +0x2a fp=0x7fffff8d8538 sp=0x7fffff8d8520 allocg(0x7fa0e0) /usr/local/go14/src/runtime/proc.c:925 +0x1f fp=0x7fffff8d8548 sp=0x7fffff8d8538 runtime.malg(0x8000, 0x7fa340) /usr/local/go14/src/runtime/proc.c:2106 +0x1f fp=0x7fffff8d8578 sp=0x7fffff8d8548 runtime.mpreinit(0x7fa920) /usr/local/go14/src/runtime/os_freebsd.c:205 +0x27 fp=0x7fffff8d8590 sp=0x7fffff8d8578 mcommoninit(0x7fa920) /usr/local/go14/src/runtime/proc.c:201 +0xc9 fp=0x7fffff8d85b8 sp=0x7fffff8d8590 runtime.schedinit() /usr/local/go14/src/runtime/proc.c:138 +0x55 fp=0x7fffff8d85e0 sp=0x7fffff8d85b8 runtime.rt0_go(0x7fffff8d8618, 0x4, 0x7fffff8d8618, 0x0, 0x0, 0x4, 0x7fffffffe480, 0x7fffffffe4c5, 0x7fffffffe4cb, 0x7fffffffe4ce, ...) /usr/local/go14/src/runtime/asm_amd64.s:95 +0x116 fp=0x7fffff8d85e8 sp=0x7fffff8d85e0 *** Error code 2
Created attachment 207211 [details] ASLR buld fix Patch to fix the build, based on Antoine comment above.
(In reply to Dmitri Goutnik from comment #5) MAP_FIXED alone is quite unsafe, you might destroy existing mapping at the specified address. I suggest you to add MAP_EXCL as well, see the mmap(2) man page for explanation.
Created attachment 207218 [details] patch file Add MAP_EXCL, bump PORTREVISION while here. Builds ok on 120a, 120i with ASRL on.
Created attachment 207430 [details] patch file Make go14 actually able to bootstrap lang/go on i386.
(In reply to Baptiste Daroussin from comment #3) On FreeBSD 12.1-PRERELEASE #0 r352284M: Sat Sep 14 07:08:40 AEST 2019, with the patch applied. I have built go14 (1.4.3_5) and used to build other applications in amd64 but not an i386 jail. kern.elf64.aslr.stack_gap: 0 # this is required due to issues with ntpd in host kern.elf64.aslr.pie_enable: 1 kern.elf64.aslr.enable: 1 kern.elf32.aslr.stack_gap=3 kern.elf32.aslr.pie_enable=1 kern.elf32.aslr.enable=1 kern.elf32.nxstack=1 vm.cluster_anon=1 # The default but others mentioned it Go was built and used to build security/vuls (successfully on amd64 jail) with this outcome in the i386 jails... /usr/local/go/pkg/tool/freebsd_386/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -buildmode=exe -buildid=0tjvD8tux_zGvAh0x9fX/1j0VZJ1DOqHq_tWso3bW/cZbhax9_KEo4DJrh1SQi/0tjvD8tux_zGvAh0x9fX -X main.version=0.6.1 -extld=/usr/local/libexec/ccache/cc $WORK/b001/_pkg_.a # _/var/ports/usr/ports/security/vuls/work/src/github.com/future-architect/vuls /usr/local/go/pkg/tool/freebsd_386/link: running /usr/local/libexec/ccache/cc failed: exit status 1 cc: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument] ld: error: failed to open $WORK/b001/exe/a.out: Cannot allocate memory cc: error: linker command failed with exit code 1 (use -v to see invocation) This box has 24G and at the time 14G Free. Over multiple runs, the cumulative changes were unsuccessful until aslr was disabled. Setting kern.elf32.aslr.stack_gap=0 did not change the result. then kern.elf32.aslr.pie_enable=0 but kern.elf32.aslr.enable=0 Did result in a successful build of (the only thing I was after) security/vuls. Please note that go14 did build, so in that sense, yes the PR could be closed but... I think more data points are required.
(In reply to dewayne from comment #9) Hi, Which go14 patch did you apply? The patch that I initially posted was not correct and was causing OOM issues similar to what you're seeing. With the currently attached patch I'm able to do a poudriere bulk of lang/go14, lang/go and security/vuls in i386 jail without errors, with ASLR both enabled and disabled. $ sysctl -a | grep aslr kern.elf32.aslr.stack_gap: 3 kern.elf32.aslr.honor_sbrk: 1 kern.elf32.aslr.pie_enable: 1 kern.elf32.aslr.enable: 1 kern.elf64.aslr.stack_gap: 0 kern.elf64.aslr.honor_sbrk: 1 kern.elf64.aslr.pie_enable: 1 kern.elf64.aslr.enable: 1 # poudriere bulk -j120i -C lang/go14 lang/go security/vuls ... [00:05:12] Built ports: lang/go14 lang/go security/vuls [120i-default] [2019-09-14_13h28m16s] [committing:] Queued: 3 Built: 3 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: 00:05:11 This is on 12.1-PRERELEASE amd64 r352284
(In reply to Dmitri Goutnik from comment #10) Hi Dmitri, I applied the patch-set from: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=207430 containing +enum +{ + MAP_EXCL = 0x4000 +}; + - p = runtime·mmap(v, n, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0); + p = runtime·mmap(v, n, PROT_READ|PROT_WRITE, MAP_ANON|MAP_FIXED|MAP_EXCL|MAP_PRIVATE, -, 0);
Any progress on this?
(In reply to Miyashita Touka from comment #12) Hi Miyashita, With aslr enabled, lang/go14 builds go14-1.4.3_6 nicely on both i386 and amd64, running FreeBSD 12.1-STABLE #22 r353671M; with: kern.elf64.aslr.stack_gap=1 kern.elf64.aslr.honor_sbrk=1 kern.elf64.aslr.pie_enable=1 kern.elf64.aslr.enable=1 kern.elf64.pie_base=16912384 kern.elf64.nxstack=1 kern.elf64.fallback_brand=-1 kern.elf32.aslr.stack_gap=1 kern.elf32.aslr.honor_sbrk=1 kern.elf32.aslr.pie_enable=1 kern.elf32.aslr.enable=1 kern.elf32.pie_base=16781312 kern.elf32.read_exec=0 kern.elf32.nxstack=1 kern.elf32.fallback_brand=-1 vm.cluster_anon=1
lang/go was switched to the new bootstrap and lang/go14 was removed by r528577.