Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: SIGSEGV in mmap_trampoline on openbsd-386-64 builder #46080

Closed
bcmills opened this issue May 10, 2021 · 14 comments
Closed

runtime: SIGSEGV in mmap_trampoline on openbsd-386-64 builder #46080

bcmills opened this issue May 10, 2021 · 14 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-OpenBSD
Milestone

Comments

@bcmills
Copy link
Contributor

bcmills commented May 10, 2021

2021-05-07T20:56:39-f05e912/openbsd-386-64

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x2 addr=0x6e35a000 pc=0x80aa221]

runtime stack:
runtime.throw({0x8268bef, 0x2a})
	/tmp/workdir/go/src/runtime/panic.go:1198 +0x64
runtime.sigpanic()
	/tmp/workdir/go/src/runtime/signal_unix.go:719 +0x22b
runtime.mmap_trampoline()
	/tmp/workdir/go/src/runtime/sys_openbsd_386.s:293 +0x61

As far as I can tell, mmap_trampoline was added to the openbsd/386 configuration in CL 287653 for #36435 (CC @4a6f656c @cherrymui), so this looks like a regression in Go 1.17 (CC @golang/release).

(Note that that change only affects openbsd/386 — which is not a first-class port — so this doesn't need to be a release-blocker.)

@bcmills bcmills added OS-OpenBSD NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 10, 2021
@bcmills bcmills added this to the Go1.17 milestone May 10, 2021
@bcmills
Copy link
Contributor Author

bcmills commented May 10, 2021

This may be a newly-changed failure mode for an existing bug: the other stack traces involved are very similar to #36563 (CC @stamblerre @matloob).

@bcmills
Copy link
Contributor Author

bcmills commented May 10, 2021

I wonder if this is a symptom of a missed error check somewhere when the program is out of memory — the gcimporter test seems to be particularly memory-intensive (#45931).

@jrick
Copy link
Contributor

jrick commented May 10, 2021

all of these failures have os/exec.(*Cmd).Run in the trace. Related to #34988?

@prattmic
Copy link
Member

While I don't see anymore mmap_trampoline failures, x/tools has lots of other SIGSEGV failures on openbsd-386-64. e.g.,

https://build.golang.org/log/548414383c6f14e6524f77ac7e79f32af96334b7
https://build.golang.org/log/1944f9b296bb4fa0ab920223e4e799970aade846
https://build.golang.org/log/5cffaa54a45cddc2890f00c3d4919686b8ed7144

In fact almost every openbsd-386-64 failure on https://build.golang.org/?repo=golang.org%2fx%2ftools right now is some variation of this SIGSEGV failure.

Quite notably, every crash I've seen so far is while running golang.org/x/tools/go/internal/gcimporter_test.TestIExportData_stdlib.

@prattmic
Copy link
Member

I managed to reproduce a crash on a gomote first try:

$ gomote create openbsd-386-64
$ GOROOT=$(pwd) gomote push ${MOTE?}
$ GOROOT=$(pwd) gomote run ${MOTE?} ./go/src/make.bash
$ GOROOT=$(pwd) gomote run -e GOPATH=/tmp/workdir/gopath ${MOTE?} /tmp/workdir/go/bin/go get golang.org/x/tools
$ GOROOT=$(pwd) gomote run -e GOPATH=/tmp/workdir/gopath -dir /tmp/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.3 -e PATH=/tmp/workdir/go/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin ${MOTE?} /tmp/workdir/go/bin/go test -short golang.org/x/tools/...
...
ok      golang.org/x/tools/go/internal/gccgoimporter    0.137s                                                                               
haserrors/haserrors.go:2:22: cannot convert "" (untyped string constant) to untyped int                                                                                                                                                                                                   
haserrors/haserrors.go:3:18: undeclared name: undefined                                                                                      
fatal error: unexpected signal during runtime execution                                                                                                                                                                                                                                   
[signal SIGSEGV: segmentation violation code=0x1 addr=0x45ce6141 pc=0x2cdc4521]                                                                                                                                                                                                           
                                                                                                                                             
runtime stack:                                                                                                                               
runtime: unexpected return pc for runtime.sigpanic called from 0x2cdc4521                                                                                                                                                                                                                 
stack: frame={sp:0x3c072ff0, fp:0x3c073008} stack=[0x3c033514,0x3c073114)
0x3c072f70:  0x0807bcb7 <runtime.dopanic_m+0x00000217>  0x0807b574 <runtime.throw+0x00000064>  0x3c072fdc  0x00000000 
0x3c072f80:  0x620003c0  0x01000001  0x0000001f  0x2cdc4521 
0x3c072f90:  0x45ce6141  0x00000001  0x00000001  0x08264fcb 
0x3c072fa0:  0x0807b7c5 <runtime.fatalthrow.func1+0x00000045>  0x620003c0  0x0807b574 <runtime.throw+0x00000064>  0x3c072fdc 
0x3c072fb0:  0x00000001  0x3c072fdc  0x0807b574 <runtime.throw+0x00000064>  0x620003c0 
0x3c072fc0:  0x0807b774 <runtime.fatalthrow+0x00000054>  0x3c072fc8  0x0807b780 <runtime.fatalthrow.func1+0x00000000>  0x620003c0 
0x3c072fd0:  0x0807b574 <runtime.throw+0x00000064>  0x3c072fdc  0x0807b574 <runtime.throw+0x00000064>  0x3c072fe0 
0x3c072fe0:  0x0807b580 <runtime.throw.func1+0x00000000>  0x082691a0  0x0000002a  0x08090d3b <runtime.sigpanic+0x0000022b> 
0x3c072ff0: <0x082691a0  0x0000002a  0x6202c000  0x2cdc451e 
0x3c073000:  0x620003c0 !0x2cdc4521 >0x620003c0  0x4cd76f30 
0x3c073010:  0x3c07303c  0x2cd9039a  0x3c073020  0x00000000 
0x3c073020:  0x00000000  0x00000000  0x00004e20  0x08097d2a <runtime.libcCall+0x0000005a> 
0x3c073030:  0x53a2037b  0x3c073054  0x3c0730a4  0x3c073048 
0x3c073040:  0x080aa3d4 <runtime.usleep_trampoline+0x00000014>  0x00000014  0x6202c000  0x080a9133 <runtime.asmcgocall+0x00000053> 
0x3c073050:  0x3c0730a4  0x00000098  0x620003c0  0x00000000 
0x3c073060:  0x62000301  0x620003c0  0x62258000  0x08088db1 <runtime.retake+0x00000281> 
0x3c073070:  0x083df044  0x00000001  0x00000000  0x08097d2a <runtime.libcCall+0x0000005a> 
0x3c073080:  0x080aa3c0 <runtime.usleep_trampoline+0x00000000>  0x3c0730a4 
runtime.throw({0x82691a0, 0x2a})
        /tmp/workdir/go/src/runtime/panic.go:1198 +0x64
runtime: unexpected return pc for runtime.sigpanic called from 0x2cdc4521
stack: frame={sp:0x3c072ff0, fp:0x3c073008} stack=[0x3c033514,0x3c073114)
0x3c072f70:  0x0807bcb7 <runtime.dopanic_m+0x00000217>  0x0807b574 <runtime.throw+0x00000064>  0x3c072fdc  0x00000000 
0x3c072f80:  0x620003c0  0x01000001  0x0000001f  0x2cdc4521 
0x3c072f90:  0x45ce6141  0x00000001  0x00000001  0x08264fcb 
0x3c072fa0:  0x0807b7c5 <runtime.fatalthrow.func1+0x00000045>  0x620003c0  0x0807b574 <runtime.throw+0x00000064>  0x3c072fdc 
0x3c072fb0:  0x00000001  0x3c072fdc  0x0807b574 <runtime.throw+0x00000064>  0x620003c0 
0x3c072fc0:  0x0807b774 <runtime.fatalthrow+0x00000054>  0x3c072fc8  0x0807b780 <runtime.fatalthrow.func1+0x00000000>  0x620003c0 
0x3c072fd0:  0x0807b574 <runtime.throw+0x00000064>  0x3c072fdc  0x0807b574 <runtime.throw+0x00000064>  0x3c072fe0 
0x3c072fe0:  0x0807b580 <runtime.throw.func1+0x00000000>  0x082691a0  0x0000002a  0x08090d3b <runtime.sigpanic+0x0000022b> 
0x3c072ff0: <0x082691a0  0x0000002a  0x6202c000  0x2cdc451e 
0x3c073000:  0x620003c0 !0x2cdc4521 >0x620003c0  0x4cd76f30 
0x3c073010:  0x3c07303c  0x2cd9039a  0x3c073020  0x00000000 
0x3c073020:  0x00000000  0x00000000  0x00004e20  0x08097d2a <runtime.libcCall+0x0000005a> 
0x3c073030:  0x53a2037b  0x3c073054  0x3c0730a4  0x3c073048 
0x3c073040:  0x080aa3d4 <runtime.usleep_trampoline+0x00000014>  0x00000014  0x6202c000  0x080a9133 <runtime.asmcgocall+0x00000053> 
0x3c073050:  0x3c0730a4  0x00000098  0x620003c0  0x00000000 
0x3c073060:  0x62000301  0x620003c0  0x62258000  0x08088db1 <runtime.retake+0x00000281> 
0x3c073070:  0x083df044  0x00000001  0x00000000  0x08097d2a <runtime.libcCall+0x0000005a> 
0x3c073080:  0x080aa3c0 <runtime.usleep_trampoline+0x00000000>  0x3c0730a4 
runtime.sigpanic()
        /tmp/workdir/go/src/runtime/signal_unix.go:719 +0x22b

...

(Per @bcmills I'm certainly not holding modules right here, but it works...)

@prattmic
Copy link
Member

I've been unable to get this to reproduce more than once on a gomote, it only crashes the very first time it runs. So always run in a new gomote. :)

#!/bin/bash

MOTE=$(gomote create openbsd-386-64)
echo ${MOTE?}
GOROOT=$(pwd) gomote push ${MOTE?}
GOROOT=$(pwd) gomote run ${MOTE?} ./go/src/make.bash
GOROOT=$(pwd) gomote run -e GOPATH=/tmp/workdir/gopath ${MOTE?} /tmp/workdir/go/bin/go get golang.org/x/tools
GOROOT=$(pwd) gomote run -e GOPATH=/tmp/workdir/gopath -dir /tmp/workdir/gopath/pkg/mod/golang.org/x/tools@v0.1.3 -e PATH=/tmp/workdir/go/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin ${MOTE?} /tmp/workdir/go/bin/go test -short golang.org/x/tools/...

@pmalek-sumo
Copy link

I believe I have just experienced something similar to #46080 (comment) on darwin (without any mention of mmap_trampoline though) using go1.17-beta1

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0xb01dfacedebac1e pc=0x7fff6d3a870a]

runtime stack:
runtime: unexpected return pc for runtime.sigpanic called from 0x7fff6d3a870a
stack: frame={sp:0x7ffeefbfea88, fp:0x7ffeefbfead8} stack=[0x7ffeefb7fb28,0x7ffeefbfeb90)
0x00007ffeefbfe988:  0x01007ffeefbfe9a8  0x0000000000000004
0x00007ffeefbfe998:  0x000000000000001f  0x00007fff6d3a870a
0x00007ffeefbfe9a8:  0x0b01dfacedebac1e  0x0000000000000001
0x00007ffeefbfe9b8:  0x0000000004038df1 <runtime.throw+0x0000000000000071>  0x00007ffeefbfea58
0x00007ffeefbfe9c8:  0x0000000007f6135b  0x00007ffeefbfea10
0x00007ffeefbfe9d8:  0x00000000040390a8 <runtime.fatalthrow.func1+0x0000000000000048>  0x000000000ae29780
0x00007ffeefbfe9e8:  0x0000000000000001  0x0000000000000001
0x00007ffeefbfe9f8:  0x00007ffeefbfea58  0x0000000004038df1 <runtime.throw+0x0000000000000071>
0x00007ffeefbfea08:  0x000000000ae29780  0x00007ffeefbfea48
0x00007ffeefbfea18:  0x0000000004039030 <runtime.fatalthrow+0x0000000000000050>  0x00007ffeefbfea28
0x00007ffeefbfea28:  0x0000000004039060 <runtime.fatalthrow.func1+0x0000000000000000>  0x000000000ae29780
0x00007ffeefbfea38:  0x0000000004038df1 <runtime.throw+0x0000000000000071>  0x00007ffeefbfea58
0x00007ffeefbfea48:  0x00007ffeefbfea78  0x0000000004038df1 <runtime.throw+0x0000000000000071>
0x00007ffeefbfea58:  0x00007ffeefbfea60  0x0000000004038e20 <runtime.throw.func1+0x0000000000000000>
0x00007ffeefbfea68:  0x0000000007fbefdd  0x000000000000002a
0x00007ffeefbfea78:  0x00007ffeefbfeac8  0x000000000404f556 <runtime.sigpanic+0x0000000000000396>
0x00007ffeefbfea88: <0x0000000007fbefdd  0x000000000ae29780
0x00007ffeefbfea98:  0x00007ffeefbfeb08  0x0000000004029c26 <runtime.(*mheap).allocSpan+0x0000000000000546>
0x00007ffeefbfeaa8:  0x000000000ae52f68  0x000000000404028f <runtime.execute+0x000000000000012f>
0x00007ffeefbfeab8:  0x000000c0000001d8  0x0000000200000001
0x00007ffeefbfeac8:  0x00007ffeefbfeb10 !0x00007fff6d3a870a
0x00007ffeefbfead8: >0x00007ffeefbfeb10  0x000000000ac50000
0x00007ffeefbfeae8:  0x00000000000006ba  0x00000000043a3305 <golang.org/x/sys/unix.libc_ioctl_trampoline+0x0000000000000005>
0x00007ffeefbfeaf8:  0x000000000406eebf <runtime.syscall+0x000000000000001f>  0x000000c00063f4a0
0x00007ffeefbfeb08:  0x00007ffeefbfeb50  0x000000c00063f470
0x00007ffeefbfeb18:  0x000000000406ccf0 <runtime.asmcgocall+0x0000000000000070>  0x0000000000000001
0x00007ffeefbfeb28:  0x000000c000001900  0x1900000400000002
0x00007ffeefbfeb38:  0x000000000ae29780  0x000000c0000001a0
0x00007ffeefbfeb48:  0x0000000000000bb8  0x000000c0000001a0
0x00007ffeefbfeb58:  0x000000000406ae09 <runtime.systemstack+0x0000000000000049>  0x0000000000000004
0x00007ffeefbfeb68:  0x000000000864b340  0x000000000ae29780
0x00007ffeefbfeb78:  0x00007ffeefbfebc0  0x000000000406ad05 <runtime.mstart+0x0000000000000005>
0x00007ffeefbfeb88:  0x000000000406acbd <runtime.rt0_go+0x000000000000013d>
runtime.throw({0x7fbefdd, 0xae29780})
        runtime/panic.go:1198 +0x71
runtime: unexpected return pc for runtime.sigpanic called from 0x7fff6d3a870a
stack: frame={sp:0x7ffeefbfea88, fp:0x7ffeefbfead8} stack=[0x7ffeefb7fb28,0x7ffeefbfeb90)
0x00007ffeefbfe988:  0x01007ffeefbfe9a8  0x0000000000000004
0x00007ffeefbfe998:  0x000000000000001f  0x00007fff6d3a870a
0x00007ffeefbfe9a8:  0x0b01dfacedebac1e  0x0000000000000001
0x00007ffeefbfe9b8:  0x0000000004038df1 <runtime.throw+0x0000000000000071>  0x00007ffeefbfea58
0x00007ffeefbfe9c8:  0x0000000007f6135b  0x00007ffeefbfea10
0x00007ffeefbfe9d8:  0x00000000040390a8 <runtime.fatalthrow.func1+0x0000000000000048>  0x000000000ae29780
0x00007ffeefbfe9e8:  0x0000000000000001  0x0000000000000001
0x00007ffeefbfe9f8:  0x00007ffeefbfea58  0x0000000004038df1 <runtime.throw+0x0000000000000071>
0x00007ffeefbfea08:  0x000000000ae29780  0x00007ffeefbfea48
0x00007ffeefbfea18:  0x0000000004039030 <runtime.fatalthrow+0x0000000000000050>  0x00007ffeefbfea28
0x00007ffeefbfea28:  0x0000000004039060 <runtime.fatalthrow.func1+0x0000000000000000>  0x000000000ae29780
0x00007ffeefbfea38:  0x0000000004038df1 <runtime.throw+0x0000000000000071>  0x00007ffeefbfea58
0x00007ffeefbfea48:  0x00007ffeefbfea78  0x0000000004038df1 <runtime.throw+0x0000000000000071>
0x00007ffeefbfea58:  0x00007ffeefbfea60  0x0000000004038e20 <runtime.throw.func1+0x0000000000000000>
0x00007ffeefbfea68:  0x0000000007fbefdd  0x000000000000002a
0x00007ffeefbfea78:  0x00007ffeefbfeac8  0x000000000404f556 <runtime.sigpanic+0x0000000000000396>
0x00007ffeefbfea88: <0x0000000007fbefdd  0x000000000ae29780
0x00007ffeefbfea98:  0x00007ffeefbfeb08  0x0000000004029c26 <runtime.(*mheap).allocSpan+0x0000000000000546>
0x00007ffeefbfeaa8:  0x000000000ae52f68  0x000000000404028f <runtime.execute+0x000000000000012f>
0x00007ffeefbfeab8:  0x000000c0000001d8  0x0000000200000001
0x00007ffeefbfeac8:  0x00007ffeefbfeb10 !0x00007fff6d3a870a
0x00007ffeefbfead8: >0x00007ffeefbfeb10  0x000000000ac50000
0x00007ffeefbfeae8:  0x00000000000006ba  0x00000000043a3305 <golang.org/x/sys/unix.libc_ioctl_trampoline+0x0000000000000005>
0x00007ffeefbfeaf8:  0x000000000406eebf <runtime.syscall+0x000000000000001f>  0x000000c00063f4a0
0x00007ffeefbfeb08:  0x00007ffeefbfeb50  0x000000c00063f470
0x00007ffeefbfeb18:  0x000000000406ccf0 <runtime.asmcgocall+0x0000000000000070>  0x0000000000000001
0x00007ffeefbfeb28:  0x000000c000001900  0x1900000400000002
0x00007ffeefbfeb38:  0x000000000ae29780  0x000000c0000001a0
0x00007ffeefbfeb48:  0x0000000000000bb8  0x000000c0000001a0
0x00007ffeefbfeb58:  0x000000000406ae09 <runtime.systemstack+0x0000000000000049>  0x0000000000000004
0x00007ffeefbfeb68:  0x000000000864b340  0x000000000ae29780
0x00007ffeefbfeb78:  0x00007ffeefbfebc0  0x000000000406ad05 <runtime.mstart+0x0000000000000005>
0x00007ffeefbfeb88:  0x000000000406acbd <runtime.rt0_go+0x000000000000013d>
runtime.sigpanic()
        runtime/signal_unix.go:719 +0x396

goroutine 1 [syscall, locked to thread]:
syscall.syscall(0x43a3300, 0x1, 0x40487413, 0xc00063f530)
        runtime/sys_darwin.go:22 +0x3b fp=0xc00063f4a0 sp=0xc00063f480 pc=0x40696fb
syscall.syscall(0x4079766, 0x20, 0xc00063f558, 0x4079698)
        <autogenerated>:1 +0x26 fp=0xc00063f4e8 sp=0xc00063f4a0 pc=0x406f706
golang.org/x/sys/unix.ioctl(0x7ed4109, 0x4, 0x10000040171f4)
        golang.org/x/sys@v0.0.0-20210426230700-d19ff857e887/unix/zsyscall_darwin_amd64.go:690 +0x39 fp=0xc00063f518 sp=0xc00063f4e8 pc=0x43a22f9
golang.org/x/sys/unix.IoctlGetTermios(...)
        golang.org/x/sys@v0.0.0-20210426230700-d19ff857e887/unix/ioctl.go:73
github.com/mattn/go-isatty.IsTerminal(0x7ed4109)
        github.com/mattn/go-isatty@v0.0.12/isatty_bsd.go:10 +0x50 fp=0xc00063f588 sp=0xc00063f518 pc=0x5007cb0
github.com/fatih/color.init()
        github.com/fatih/color@v1.9.0/color.go:21 +0x7a fp=0xc00063f5c0 sp=0xc00063f588 pc=0x50080ba
runtime.doInit(0xac66220)
        runtime/proc.go:6490 +0x123 fp=0xc00063f6f8 sp=0xc00063f5c0 pc=0x40486e3
runtime.doInit(0xac7ec00)
        runtime/proc.go:6467 +0x71 fp=0xc00063f830 sp=0xc00063f6f8 pc=0x4048631
runtime.doInit(0xac83520)
        runtime/proc.go:6467 +0x71 fp=0xc00063f968 sp=0xc00063f830 pc=0x4048631
runtime.doInit(0xac7f440)
        runtime/proc.go:6467 +0x71 fp=0xc00063faa0 sp=0xc00063f968 pc=0x4048631
runtime.doInit(0xac79900)
        runtime/proc.go:6467 +0x71 fp=0xc00063fbd8 sp=0xc00063faa0 pc=0x4048631
runtime.doInit(0xac7cd40)
        runtime/proc.go:6467 +0x71 fp=0xc00063fd10 sp=0xc00063fbd8 pc=0x4048631
runtime.doInit(0xac881c0)
        runtime/proc.go:6467 +0x71 fp=0xc00063fe48 sp=0xc00063fd10 pc=0x4048631
runtime.doInit(0xac82fe0)
        runtime/proc.go:6467 +0x71 fp=0xc00063ff80 sp=0xc00063fe48 pc=0x4048631
runtime.main()
        runtime/proc.go:238 +0x1e6 fp=0xc00063ffe0 sp=0xc00063ff80 pc=0x403b446
runtime.goexit()
        runtime/asm_amd64.s:1581 +0x1 fp=0xc00063ffe8 sp=0xc00063ffe0 pc=0x406cfe1

pmalek-sumo pushed a commit to SumoLogic/sumologic-otel-collector that referenced this issue Jul 2, 2021
Due to a beta toolchain bug [1] don't use go1.17-beta1 for darwin builds,
tests and release binaries (to release for all OSes using the same
toolchain).

[1]: golang/go#46080 (comment)
@cherrymui
Copy link
Member

@pmalek-sumo yours looks like #46645. Could you try updating golang.org/x/sys ? Thanks.

@pmalek-sumo
Copy link

@cherrymui Thanks! Adding the following replace helped

golang.org/x/sys => golang.org/x/sys v0.0.0-20210630005230-0f9fa26af87c

@bcmills
Copy link
Contributor Author

bcmills commented Jul 14, 2021

@pmalek-sumo, a replace directive is not appropriate for this. Use go get to upgrade dependencies (it adds require directives, not replace).

@pmalek-sumo
Copy link

@bcmills Why specifically is that not appropriate here?

I'm using it because of the way the config for https://github.com/open-telemetry/opentelemetry-collector-builder is structured i.e. the code is generated based on it.

@bcmills
Copy link
Contributor Author

bcmills commented Jul 14, 2021

@pmalek-sumo, the replace directive replaces the source code for (all versions of) the indicated module with the source code at the replacement path. It doesn't add the replacement version itself to the module graph — that version is used only to identify which copy of the source code to swap in. So if you later add a dependency that requires a higher version of that module, that version will also be replaced and you'll end up with a broken build.

In contrast, the require directive increases the minimum version of the indicated module. If other requirements are added, go get and go mod tidy will upgrade that version as needed to satisfy those requirements and ensure overall consistency.

replace is a big hammer, intended for local development and to fix serious, complex problems in the module dependency graph. require (managed via go get and go mod tidy) is the intended mechanism for day-to-day dependency upgrades.

@pmalek-sumo
Copy link

Thanks for the explanation!

We might need to rethink then the approach in the config file then and use require directives (with option for replace)

@mknyszek mknyszek modified the milestones: Go1.17, Backlog Aug 18, 2021
@gopherbot
Copy link

Change https://golang.org/cl/357370 mentions this issue: dashboard: remove OpenBSD 6.4 builders

@golang golang locked and limited conversation to collaborators Oct 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-OpenBSD
Projects
None yet
Development

No branches or pull requests

7 participants